perm filename COMMON.MSG[COM,LSP]13 blob
sn#683468 filedate 1982-10-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Common.1[com,lsp] is the portion of the Common Lisp file preceeding this.
C00003 ENDMK
C⊗;
;;; Common.1[com,lsp] is the portion of the Common Lisp file preceeding this.
∂02-Oct-82 0033 MOON at SCRC-TENEX DEFSTRUCT options syntax
Date: Saturday, 2 October 1982 03:30-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp at SU-AI
Subject: DEFSTRUCT options syntax
In-reply-to: The message of 1 Oct 1982 08:48-EDT from Scott E. Fahlman <Fahlman at Cmu-20c>
Date: Friday, 1 October 1982 08:48-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
....
my point is just that OPEN is pretty much like the others.
Except that it is a function.
I'm uneasy about making special forms too special, and creating forms
that the user cannot duplicate with macros or some such.
No one proposes to make forms that the user cannot duplicate with macros.
Indeed, I can think of no possible way to do that.
Perhaps we can
extend the basic keyword mechanism to allow keyword/value, but also
allow calling forms like (foo :key1 value1 (:key2 value2a value2b) ...)
However, coming up with an attractive way to specify this in a macro's
lambda-list will be pretty tough.
I assume you don't mean doing this for functions. That would be utterly wrong.
We could easily add another & word to DEFMACRO if we decide it is desirable
to have an even more trivial way to accept such syntax in macros than the
straightforward way of looping over the form checking LISTP and CAR.
∂02-Oct-82 0928 Guy.Steele at CMU-10A Apalled
Date: 2 October 1982 1229-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Apalled
A marvelous word, this. Perhaps KMP meant that Common LISP is in
danger of being "APPLEd", that is, forced into the Procrustean bed
of an APPLE's memory size. This danger can be avoided by making the
language so large that it cannot possiblt be shoehorned into an APPLE.
However, I think this is already the case without RESTART being
added.
Or perhaps Common LISP is being "APL'd", but better to blame that on
REDUCE and MAP than on RESTART.
But most likely is that he simply wished to "applaud" the RESTART form.
(Sorry, KMP, don't mean to tease, but it's wonderful how this typo
landed splat between four or five applicable words.)
--Quux
∂02-Oct-82 0939 Guy.Steele at CMU-10A keyword pairs and DEFSTRUCT
Date: 2 October 1982 1240-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: keyword pairs and DEFSTRUCT
I am in sympathy with leaving DEFSTRUCT as is. Indeed, there may be
something odd about DEF-forms. OPEN was the biggest thorn, to my mind.
∂03-Oct-82 1104 Scott E. Fahlman <Fahlman at Cmu-20c> Documentation strings
Date: Sunday, 3 October 1982 14:03-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: common-lisp at SU-AI
Subject: Documentation strings
Gary Brown noticed that DEFMACRO and DEFSTRUCT are not documented as
taking documentation strings. DEFMACRO certainly should, since its form
parallels that of DEFUN, and adding this to DEFSTRUCT seems to be a good
idea as well. Any problems with this?
-- Scott
∂04-Oct-82 0046 Alan Bawden <ALAN at MIT-MC> Documentation strings in defstruct
Date: 4 October 1982 03:45-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: Documentation strings in defstruct
To: common-lisp at SU-AI
Date: Sunday, 3 October 1982 14:03-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
Gary Brown noticed that DEFMACRO and DEFSTRUCT are not documented as
taking documentation strings. DEFMACRO certainly should, since its form
parallels that of DEFUN, and adding this to DEFSTRUCT seems to be a good
idea as well. Any problems with this?
How about:
(defstruct (spaceman (:include person)
(:documentation "A spaceman.
The definition of a spaceman includes the definition of a person.
Additionally a spaceman has a helmit-size and a favorite-beverage.
The default favorite-beverage is Tang (tm)."))
helmet-size
(favorite-beverage 'tang))
∂04-Oct-82 0759 Scott E. Fahlman <Fahlman at Cmu-20c> Documentation strings in defstruct
Date: Monday, 4 October 1982 10:49-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Alan Bawden <ALAN at MIT-MC>
Cc: common-lisp at SU-AI
Subject: Documentation strings in defstruct
The use of a :DOCUMENTATION keyword in DEFSTRUCT looks OK, modulo the
auto-fill issues discussed earlier.
-- Scott
∂04-Oct-82 1420 Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC> keyword pairs and OPEN
Date: Monday, 4 October 1982, 17:08-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: keyword pairs and OPEN
To: Guy.Steele at CMU-10A, common-lisp at SU-AI
In-reply-to: The message of 2 Oct 82 12:40-EDT from Guy.Steele at CMU-10A
Speaking of OPEN being the biggest thorn, I owe you a proposal. Here it
is.
OPEN takes a filename as its first argument. The rest of its arguments
are keyword/value pairs.
WITH-OPEN-STREAM's first subform is a list of a variable (to be bound to
a stream), a filename, and the rest of the elements are keyword/value
pairs.
The keywords are as follows, with their possible values and defaults:
:DIRECTION :INPUT (the default), :OUTPUT, :APPEND, :OVERWRITE, :PROBE
:INPUT - The file is expected to exist. Output operations are not allowed.
:OUTPUT - The file is expected to not exist. A new file is created. Input
operations are not allowed.
:APPEND - The file is expected to exist. Input operations are not allowed.
New characters are appened to the end of the existing file.
:OVERWRITE - The file is expected to exist. All operations are allowed.
The "file pointer" starts at the beginning of the file.
:PROBE - The file may or may not exist. Neither input nor output operations
are allowed. Furthermore, it is not necessary to close the stream.
:CHARACTERS T (the default), NIL, :DEFAULT
T - Open the file for reading/writing of characters.
NIL - Open the file for reading/writing of bytes (non-negative integers).
:DEFAULT - Let the file system decide, based on the file it finds.
:BYTE-SIZE a fixnum or :DEFAULT (the default)
a fixnum - Use this byte size.
:DEFAULT - Let the file system decide, based on the file it finds.
:IF-EXISTS :ERROR (the default), :NEW-VERSION, :RENAME,
:RENAME-AND-DELETE, :OVERWRITE, :APPEND, :REPLACE
Ignored if direction is not :OUTPUT. This tells what to do if the file
that you're trying to create already exists.
:ERROR - Signal an error.
:NEW-VERSION - Create a file with the same filename except with "latest" version.
:RENAME - Rename the existing file to something else and proceed.
:RENAME-AND-DELETE - Rename the existing file and delete (but don't expunge,
if your system has undeletion) it, and proceed.
:OVERWRITE - Open for :OVERWRITE instead. (If your file system doesn't have
this, use :RENAME-AND-DELETE if you have undeletion and :RENAME otherwise.)
:APPEND - Open for :APPEND instead.
:REPLACE - Replace the existing file, deleting it when the stream is closed.
:IF-DOES-NOT-EXIST :ERROR (the default), :CREATE
Ignored if direction is neither :APPEND nor :OVERWRITE
:ERROR - Signal an error.
:CREATE - Create the file and proceed.
Notes:
I renamed :READ-ALTER to :OVERWRITE; :READ-WRITE might also be good.
The :DEFAULT values are very useful, although some systems cannot figure
out this information. :CHARACTERS :DEFAULT is especially useful for
LOAD. Having the byte size come from the file only when the option is
missing, as the latest Common Lisp manual says, is undesirable because
it makes things harder for programs that are passing the value of that
keyword argument as computed from an expression.
Example of OPEN:
(OPEN "f:>dlw>lispm.init" :DIRECTION :OUTPUT)
Example of WITH-OPEN-FILE:
(WITH-OPEN-FILE (STREAM "f:>dlw>lispm.init" :DIRECTION :OUTPUT) ...)
OPEN can be kept Maclisp compatible by recognizing whether the second
argument is a list or not. Lisp Machine Lisp does this for the benefit
of old programs. The new syntax cannot be mistaken for the old one.
I removed :ECHO because we got rid of MAKE-ECHO-STREAM at the last
meeting.
Other options that the Lisp Machine will probably have, and which might
be candidates for Common Lisp, are: :INHIBIT-LINKS, :DELETED,
:PRESERVE-DATES, and :ESTIMATED-SIZE.
∂04-Oct-82 1642 Ginder at CMU-20C dlw's OPEN proposal
Date: 4 Oct 1982 1940-EDT
From: Ginder at CMU-20C
Subject: dlw's OPEN proposal
To: steele at CMU-20C
cc: common-lisp at SU-AI
The :APPEND keyword may be misleading in conjuction with Sesame's
"write once" files. I suppose you could copy the contents of the
:APPEND'ed file into a new one and start from there and consider this
an implementation detail. Where would stuff like this be explained in
the manual? Where would the LM people's extensions be explained? I
realize that these explanations are to be in the "red pages", but does
that mean that I have to look up both the white pages and red pages
documentation for a system fun? What if it's also extended in the
yellow pages? Will red and yellow pages be inserted into the middle
of the white pages at "appropriate" places? Pointers to them?
-Joe
-------
∂04-Oct-82 2042 Guy.Steele at CMU-10A Explanation of "Sesame"
Date: 4 October 1982 2250-EDT (Monday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Explanation of "Sesame"
Sesame is the Spice file system, to which Spice LISP must eventually
interface. If we are lucky, they'll let us tell them what we need.
∂04-Oct-82 2042 Guy.Steele at CMU-10A HIC lambda macros
Date: 4 October 1982 2341-EDT (Monday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: HIC lambda macros
I have a question about the proposed lambda macros: do they occupy the
function name space, or a separate name space? That is, can I have
a lambda macro and also an ordinary macro with the same name? Or
a function and a lambda-macro with the same name?
∂04-Oct-82 2047 Howard I. Cannon <HIC at MIT-MC> HIC lambda macros
Date: 4 October 1982 23:46-EDT
From: Howard I. Cannon <HIC at MIT-MC>
Subject: HIC lambda macros
To: Guy.Steele at CMU-10A
cc: common-lisp at SU-AI
Date: 4 October 1982 2341-EDT (Monday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Re: HIC lambda macros
I have a question about the proposed lambda macros: do they occupy the
function name space, or a separate name space? That is, can I have
a lambda macro and also an ordinary macro with the same name? Or
a function and a lambda-macro with the same name?
They occupy a different namespace. On the Lisp Machine, lambda macros
reside on the LAMBDA-MACRO property of their name. However, there is
a function-spec to reference them by, so you don't need to know this.
∂04-Oct-82 2130 HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility) suggestions on floating point numbers and hash tables
Date: 5 Oct 1982 0030-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: suggestions on floating point numbers and hash tables
To: common-lisp at SU-AI
We have just finished most of the code needed to support Common Lisp
numbers, and are working on hash tables. In the process, we have
noticed a few things:
When you see 1.0, it is hard to know what the precision is. We would
like to make sure that if you write something out and read it back in,
it is EQUAL to what you started with. Thus you should consider doing
one of the following:
- adopt a convention where you can tell the precision based on the
number of digits printed. E.g. 1.00000 would be single, but
1.000000000000000 would be double. If you follow such a
convention in both READ and PRINT, it should be possible to
preserve the type. (This would replace the
READ-DEFAULT-FLOAT-FORMAT flag.) This has the advantage of being
to some extent machine-independent, in that 1.0000 might be
single-precision on the VAX and short on the DEC-20.
- always print an exponent marker, or maybe always print it when the
it is not the same as READ-DEFAULT-FLOAT-FORMAT.
(At the moment, we are always supplying an exponent marker when it is
different from the default.)
We do not notice any way to write out hash tables. We suggest that you
adopt a # syntax for that. In my opinion, it should be possible to
write out and read back in as many kinds of user data structures as is
possible.
You specify a default packing factor of .8 for hash tables. I wonder
whether you really want this number to be defined in the manual. It
seems to me that the best packing factor may well be
implementation-dependent, because it will depend upon the way the
implementors have taken certain space-time tradeoffs. For various
reasons we are looking at using a algorithm where resolving clashes will
be fairly expensive. Thus we intend to use a much lower default packing
factor. (The method involved would use less storage space per item, so
we could afford the larger tables implied.)
Finally, we wonder whether having separate MAKE-xxx-HASH-TABLE functions
but the same PUT-HASH and GET-HASH for all types is the right way to go.
At least in our implementation, the structure of all hash tables is
identical. What is different among the tables is how you compare
entries. We think it would make more sense to have one MAKE-HASH-TABLE
and separate access functions. Since the user supplies to hash table
type when he creates it, we just have to save it somewhere in the table,
and then use it behind his back to change the meaning of the access
functions. Although I don't quite know how one would use it, in
principle it would make sense to put different kinds of items into the
same hash table using different functions, something that is ruled out
by your proposal. Also, if there were only one kind of hash table, it
would be slightly easier to PRINT and READ them.
-------
∂04-Oct-82 2138 Scott E. Fahlman <Fahlman at Cmu-20c> White, red, and yellow pages
Date: Tuesday, 5 October 1982 00:37-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Ginder at CMU-20C
Cc: common-lisp at SU-AI
Subject: White, red, and yellow pages
There are a number of operating systems that will not be able to support
:APPEND to files. Where it is clear that there will be some differences
between implementations, the white pages should mention this: "Note: not
all implementations will be able to support :APPEND." Or some such.
In general, it is impossible for the white pages to flag all extensions
made by all current and future Common Lisp implementations, so you will
indeed have to be familiar with the red pages for your implementation.
Most of the extensions will be easy to remember, or will be things you
never want to use anyway; for the others, an obvious techniques is to
mark the passage in the white pages that are modified in the red.
I assume that Zetalisp will continue to have a separate manual, so their
very extensive supersetting will not be a problem.
-- Scott
∂04-Oct-82 2148 Guy.Steele at CMU-10A Moon's floating-point extractors proposal
Date: 4 October 1982 2355-EDT (Monday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Moon's floating-point extractors proposal
I support Moon's proposal, but would like to suggest that FLOAT-SIGN
be modified to
(FLOAT-SIGN x &optional (y (float 1 x)))
returns z such that x and z have same sign and (= (abs y) (abs z)).
In this way (FLOAT-SIGN x) returns 1.0 or -1.0 of the same format as x,
and FLOAT-SIGN of two arguments is what the IEEE proposal calls COPYSIGN,
a useful function indeed in numerical code.
--Guy
∂04-Oct-82 2145 STEELE at CMU-20C /BALLOT/
Date: 5 Oct 1982 0041-EDT
From: STEELE at CMU-20C
Subject: /BALLOT/
To: common-lisp at SU-AI
cc: b.steele at CMU-10A
?????????????????????????????????????????????????????????????????????????????
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
? % ================================================================= % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + # / The October 1982 Common LISP Ballot / # + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % ================================================================= % ?
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
?????????????????????????????????????????????????????????????????????????????
Here is what you have all been waiting for! I need an indication of
consensus or lack thereof on the issues that have been discussed by
network mail since the August 1982 meeting, particularly on those issues
that were deferred for proposal for which proposals have now been made.
There are 28 questions, each requiring only a one-letter answer. As always,
if you don't like any of the choices, answer "x". To make my life easier
by permitting mechanical collation of responses, please respond as follows:
(a) send a reply message to Guy.Steele @ CMU-10A.
(b) *PLEASE* be sure the string "/BALLOT/" is in the subject line,
as it is in this message (the double quotes, not the slashes,
are metasyntactic!).
(c) The very first non-blank line of your message should have
exactly 29 non-blank characters on it. The first should be a
tilde ("~") and the rest should be your votes.
You may put spaces between the letters to improve readability.
(d) Following the first non-blank line, place any remarks about
issues on which you voted "x".
Thank you for your help. I would appreciate response by Friday, October 8.
--Guy
1. How shall the case for a floating-point exponent specifier
output by PRINT and FORMAT be determined?
(a) upper case, for example 3.5E6
(b) lower case, for example 3.5e6
(c) a switch
(d) implementation-dependent
2. Shall we change the name SETF to be SET? (y) yes (n) no
3. Shall there be a type specifier QUOTE, such that (QUOTE x) = (MEMBER x)?
Then MEMBER can be eliminated; (MEMBER x y z) = (OR 'x 'y 'z). Also one can
write such things as (OR INTEGER 'FOO) instead of (OR INTEGER (MEMBER FOO)).
(y) yes (n) no
4. Shall MOON's proposal for LOAD keywords, revised as shown below, be used?
(y) yes (n) no
----------------------------------------------------------------
Date: Wednesday, 25 August 1982, 14:01-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
[slightly revised]
Here is a revised proposal:
Keyword Default Meaning
:PACKAGE NIL NIL means use file's native package, non-NIL
is a package or name of package to load into.
:VERBOSE *LOAD-VERBOSE* T means print a message saying what file is
being loaded into which package.
:PRINT NIL T means print values of forms as they are evaluated.
:ERROR T T means handle errors normally; NIL means that
a file-not-found error should return NIL
rather than signalling an error. LOAD returns
the pathname (or truename??) of the file it
loaded otherwise.
:SET-DEFAULT-PATHNAME *LOAD-SET-DEFAULT-PATHNAME*
T means update the pathname default
for LOAD from the argument, NIL means don't.
:STREAM NIL Non-NIL means this is an open stream to be
loaded from. (In the Lisp machine, the
:CHARACTERS message to the stream is used to
determine whether it contains text or binary.)
The pathname argument is presumed to be associated
with the stream, in systems where that information
is needed.
The global variables' default values are implementation dependent, according
to local conventions, and may be set by particular users according to their
personal taste.
I left out keywords to allow using a different set of defaults from the normal
one and to allow explicit control over whether a text file or a binary file
is being loaded, since these don't really seem necessary. If we put them in,
the consistent names would be :DEFAULT-PATHNAME, :CHARACTERS, and :BINARY.
----------------------------------------------------------------
5. Shall closures over dynamic variables be removed from Common LISP?
(y) yes (n) no
6. Shall LOOP, as summarized below, be included in Common LISP?
(y) yes (n) no
----------------------------------------------------------------
Date: 26 August 1982 18:51-EDT
From: David A. Moon <MOON at MIT-MC>
Here is an extremely brief summary of the proposed new LOOP design, which
has not yet been finalized. Consult the writeup on LOOP in the Lisp
Machine manual or MIT LCS TM-169 for background information. Constructive
comments are very welcome, but please reply to BUG-LOOP at MIT-ML, not to
me personally.
(LOOP form form...) repeatedly evaluates the forms.
In general the body of a loop consists of a series of clauses. Each
clause is either: a series of one or more lists, which are forms to be
evaluated for effect, delimited by a symbol or the end of the loop; or
a clause-introducing symbol followed by idiosyncratic syntax for that
kind of clause. Symbols are compared with SAMEPNAMEP. Atoms other than
symbols are in error, except where a clause's idiosyncratic syntax permits.
1. Primary clauses
1.1 Iteration driving clauses
These clauses run a local variable through a series of values and/or
generate a test for when the iteration is complete.
REPEAT <count>
FOR/AS <var> ...
CYCLE <var> ...
I won't go into the full syntax here. Features include: setting
to values before starting/on the first iteration/on iterations after
the first; iterating through list elements/conses; iterating through
sequence elements, forwards or backwards, with or without sequence-type
declaration; iterating through arithmetic progressions. CYCLE reverts
to the beginning of the series when it runs out instead of terminating
the iteration.
It is also possible to control whether or not an end-test is generated
and whether there is a special epilogue only evaluated when an individual
end-test is triggered.
1.2 Prologue and Epilogue
INITIALLY form form... forms to be evaluated before starting, but
after binding local variables.
FINALLY form form... forms to be evaluated after finishing.
1.3 Delimiter
DO a sort of semicolon needed in odd situations to terminate a clause,
for example between an INITIALLY clause and body forms when no named
clause (e.g. an iteration-driving clause) intervenes.
We prefer this over parenthesization of clauses because of the
general philosophy that it is more important to make the simple cases
as readable as possible than to make micro-improvements in the
complicated cases.
1.4 Blockname
NAMED name Gives the block generated by LOOP a name so that
RETURN-FROM may be used.
This will be changed to conform with whatever is put into Common Lisp
for named PROGs and DOs, if necessary.
2. Relevant special forms
The following special forms are useful inside the body of a LOOP. Note
that they need not appear at top level, but may be nested inside other
Lisp forms, most usefully bindings and conditionals.
(COLLECT <value> [USING <collection-mode>] [INTO <var>] [BACKWARDS]
[FROM <initial-value>] [IF-NONE <expr>] [[TYPE] <type>])
This special form signals an error if not used lexically inside a LOOP.
Each time it is evaluated, <value> is evaluated and accumulated in a way
controlled by <collection-mode>; the default is to form an ordered list.
The accumulated values are returned from the LOOP if it is finished
normally, unless INTO is used to put them into a variable (which gets
bound locally to the LOOP). Certain accumulation modes (boolean AND and
OR) cause immediate termination of the LOOP as soon as the result is known,
when not collecting into a variable.
Collection modes are extensible by the user. A brief summary of predefined
ones includes aggregated boolean tests; lists (both element-by-element and
segment-by-segment); commutative/associative arithmetic operators (plus,
times, max, min, gcd, lcm, count); sets (union, intersection, adjoin);
forming a sequence (array, string).
Multiple COLLECT forms may appear in a single loop; they are checked for
compatibility (the return value cannot both be a list of values and a
sum of numbers, for example).
(RETURN value) returns immediately from a LOOP, as from any other block.
RETURN-FROM works too, of course.
(LOOP-FINISH) terminates the LOOP, executing the epilogue and returning
any value defined by a COLLECT special form.
[Should RESTART be interfaced to LOOP, or only be legal for plain blocks?]
3. Secondary clauses
These clauses are useful abbreviations for things that can also be done
using the primary clauses and Lisp special forms. They exist to make
simple cases more readable. As a matter of style, their use is strongly
discouraged in complex cases, especially those involving complex or
nested conditionals.
3.1 End tests
WHILE <expr> (IF (NOT <expr>) (LOOP-FINISH))
UNTIL <expr> (IF <expr> (LOOP-FINISH))
3.2 Conditionals
WHEN <expr> <clause> The clause is performed conditionally.
IF <expr> <clause> synonymous with WHEN
UNLESS <expr> <clause> opposite of WHEN
AND <clause> May be suffixed to a conditional. These two
ELSE <clause> might be flushed as over-complex.
3.3 Bindings
WITH <var> ... Equivalent to wrapping LET around the LOOP.
This exists to promote readability by decreasing
indentation.
3.4 Return values
RETURN <expr> synonymous with (RETURN <expr>)
COLLECT ... synonymous with (COLLECT ...)
NCONC ... synonymous with (COLLECT ... USING NCONC)
APPEND, SUM, COUNT, MINIMIZE, etc. are analogous
ALWAYS, NEVER, THEREIS abbreviations for boolean collection
4. Extensibility
There are ways for users to define new iteration driving clauses which
I will not go into here. The syntax is more flexible than the existing
path mechanism.
There are also ways to define new kinds of collection.
5. Compatibility
The second generation LOOP will accept most first-generation LOOP forms
and execute them in the same way, although this was not a primary goal.
Some complex (and unreadable!) forms will not execute the same way or
will be errors.
6. Documentation
We intend to come up with much better examples. Examples are very
important for developing a sense of style, which is really what LOOP
is all about.
----------------------------------------------------------------
7. Regardless of the outcome of the previous question, shall CYCLE
be retained and be renamed LOOP, with the understanding that statements
of the construct must be non-atomic, and atoms as "statements" are
reserved for extensions, and any such extensions must be compatible
with the basic mening as a pure iteration construct?
(y) yes (n) no
8. Shall ARRAY-DIMENSION be changed by exchanging its arguments,
to have the array first and the axis number second, to parallel
other indexing operations?
(y) yes (n) no
9. Shall MACROEXPAND, as described below, replace the current definition?
(y) yes (n) no
----------------------------------------------------------------
Date: Sunday, 29 August 1982, 21:26-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Here is my promised proposal, with some help from Alan.
MACRO-P becomes a predicate rather than a pseudo-predicate.
Everything on pages 92-93 (29July82) is flushed.
Everything, including the compiler, expands macros by calling MACROEXPAND
or MACROEXPAND-1. A variable, *MACROEXPAND-HOOK*, is provided to allow
implementation of displacing, memoization, etc.
The easiest way to show the details of the proposal is as code. I'll try to
make it exemplary.
(DEFVAR *MACROEXPAND-HOOK* 'FUNCALL)
(DEFUN MACROEXPAND (FORM &AUX CHANGED)
"Keep expanding the form until it is not a macro-invocation"
(LOOP (MULTIPLE-VALUE (FORM CHANGED) (MACROEXPAND-1 FORM))
(IF (NOT CHANGED) (RETURN FORM))))
(DEFUN MACROEXPAND-1 (FORM)
"If the form is a macro-invocation, return the expanded form and T.
This is the only function that is allowed to call macro expander functions.
*MACROEXPAND-HOOK* is used to allow memoization."
(DECLARE (VALUES FORM CHANGED-FLAG))
(COND ((AND (PAIRP FORM) (SYMBOLP (CAR FORM)) (MACRO-P (CAR FORM)))
(LET ((EXPANDER (---get expander function--- (CAR FORM))))
---check for wrong number of arguments---
(VALUES (FUNCALL *MACROEXPAND-HOOK* EXPANDER FORM) T)))
(T FORM)))
;You can set *MACROEXPAND-HOOK* to this to get traditional displacing
(DEFUN DISPLACING-MACROEXPAND-HOOK (EXPANDER FORM)
(LET ((NEW-FORM (FUNCALL EXPANDER FORM)))
(IF (ATOM NEW-FORM)
(SETQ NEW-FORM `(PROGN ,NEW-FORM)))
(RPLACA FORM (CAR NEW-FORM))
(RPLACD FORM (CDR NEW-FORM))
FORM))
The above definition of MACROEXPAND-1 is oversimplified, since it can
also expand other things, including lambda-macros (the subject of a separate
proposal that has not been sent yet) and possibly implementation-dependent
things (substs in the Lisp machine, for example).
The important point here is the division of labor. MACROEXPAND-1 takes care
of checking the length of the macro-invocation to make sure it has the right
number of arguments [actually, the implementation is free to choose how much
of this is done by MACROEXPAND-1 and how much is done by code inserted into
the expander function by DEFMACRO]. The hook takes care of memoization. The
macro expander function is only concerned with translating one form into
another, not with bookkeeping. It is reasonable for certain kinds of
program-manipulation programs to bind the hook variable.
I introduced a second value from MACROEXPAND-1 instead of making MACROEXPAND
use the traditional EQ test. Otherwise a subtle change would have been
required to DISPLACING-MACROEXPAND-HOOK, and some writers of hooks might get
it wrong occasionally, and their code would still work 90% of the time.
Other issues:
On page 93 it says that MACROEXPAND ignores local macros established by
MACROLET. This is clearly incorrect; MACROEXPAND has to get called with an
appropriate lexical context available to it in the same way that EVAL does.
They are both parts of the interpreter. I don't have anything to propose
about this now; I just want to point out that there is an issue. I don't
think we need to deal with the issue immediately.
A related issue that must be brought up is whether the Common Lisp subset
should include primitives for accessing and storing macro-expansion
functions. Currently there is only a special form (MACRO) to set a
macro-expander, and no corresponding function. The Lisp machine expedient of
using the normal function-definition primitive (FDEFINE) with an argument of
(MACRO . expander) doesn't work in Common Lisp. Currently there is a gross
way to get the macro expander function, but no reasonable way. I don't have
a clear feeling whether there are programs that would otherwise be portable
except that they need these operations.
----------------------------------------------------------------
10. Shall all global system-defined variables have names beginning
and ending with "*", for example *PRINLEVEL* instead of PRINLEVEL
and *READ-DEFAULT-FLOAT-FORMAT* instead of READ←DEFAULT-FLOAT-FORMAT?
(y) yes (n) no
11. Same question for named constants (other than T and NIL), such as
*PI* for PI and *MOST-POSITIVE-FIXNUM* for MOST-POSITIVE-FIXNUM.
(y) yes (n) no (o) yes, but use a character other than "*"
12. Shall a checking form CHECK-TYPE be introduced as described below?
(y) yes (n) no
----------------------------------------------------------------
Date: Thursday, 26 August 1982, 03:04-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
See p.275 of the 29 July Common Lisp manual and p.275 of the revision
handed out at the Lisp conference.
I suggest that we include CHECK-ARG-TYPE in the language. Although
CHECK-ARG, CHECK-ARG-TYPE, and ASSERT have partially-overlapping
functionality, each has its own valuable uses and I think all three
ought to be in the language.
Note that CHECK-ARG and CHECK-ARG-TYPE are used when you want explicit
run-time checking, including but not limited to writing the interpreter
(which of course is written in Lisp, not machine language!).
The details:
CHECK-ARG-TYPE arg-name type &OPTIONAL type-string [macro]
If (TYPEP arg-name 'type) is false, signal an error. The error message
includes arg-name and a "pretty" English-language form of type, which
can be overridden by specifying type-string (this override is rarely
used). Proceeding from the error sets arg-name to a new value and
makes the test again.
Currently arg-name must be a variable, but it should be generalized to
any SETF'able place.
type and type-string are not evaluated.
This isn't always used for checking arguments, since the value of any
variable can be checked, but it is usually used for arguments and there
isn't an alternate name that more clearly describes what it does.
Date: 2 Sep 1982 12:30 PDT
From: JonL at PARC-MAXC
PDP10 MacLisp and VAX/NIL have had the name CHECK-TYPE for several
years for essentially this functionality (unless someone has recently renamed
it). Since it is used to certify the type of any variable's value, it did not
include the "-ARG" part. The motivation was to have a "checker" which was
more succinct than CHECK-ARGS, but which would generally open-code the
type test (and hence introduce no delay to the non-error case).
I rather prefer the semantics you suggested, namely that the second argument
to CHECK-TYPE be a type name (given the CommonLisp treatment of type
hierarchy). At some level, I'd think a "promise" of fast type checking should
be guaranteed (in compiled code) so that persons will prefer to use this
standardized facililty; without some indication of performance, one would
be tempted to write his own in order not to slow down the common case.
----------------------------------------------------------------
13. Shall a checking form CHECK-SUBSEQUENCE be introduced as described below?
(y) yes (n) no
----------------------------------------------------------------
Date: 2 Sep 1982 12:30 PDT
From: JonL at PARC-MAXC
If the general sequence functions continue to thrive in CommonLisp, I'd
like to suggest that the corresponding CHECK-SUBSEQUENCE macro (or
whatever renaming of it should occur) be included in CommonLisp.
CHECK-SUBSEQUENCE (<var> <start-index> <count>) &optional <typename>)
provides a way to certify that <var> holds a sequence datum of the type
<typename>, or of any suitable sequence type (e.g., LIST, or STRING or
VECTOR etc) if <typename> is null; and that the indicated subsequence
in it is within the size limits.
[GLS: probably <end> is more appropriate than <count> for Common LISP.]
----------------------------------------------------------------
14. Shall the functions LINE-OUT and STRING-OUT, eliminated in November,
be reinstated?
(y) yes (n) no
15. Shall the REDUCE function be added as described below?
(y) yes (n) no
----------------------------------------------------------------
Date: 3 September 1982 1756-EDT (Friday)
From: Guy.Steele at CMU-10A
I would like to mildly re-propose the REDUCE function for Common
LISP, now that adding it would require only one new function, not ten
or fifteen:
REDUCE function sequence &KEY :START :END :FROM-END :INITIAL-VALUE
The specified subsequence of "sequence" is reduced, using the "function"
of two arguments. The reduction is left-associative, unless
:FROM-END is not false, in which case it is right-associative.
If the an :INITIAL-VALUE is given, it is logically placed before the
"sequence" (after it if :FROM-END is true) and included in the
reduction operation. If no :INITIAL-VALUE is given, then the "sequence"
must not be empty. (An alternative specification: if no :INITIAL-VALUE
is given, and "sequence" is empty, then "function" is called with
zero arguments and the result returned. How about that? This idea
courtesy of Dave Touretzky.)
(REDUCE #'+ '(1 2 3 4)) => 10
(REDUCE #'- '(1 2 3 4)) => -8
(REDUCE #'- '(1 2 3 4) :FROM-END T) => -2 ;APL-style
(REDUCE #'LIST '(1 2 3 4)) => (((1 2) 3) 4)
(REDUCE #'LIST '(1 2 3 4) :FROM-END T) => (1 (2 (3 4)))
(REDUCE #'LIST '(1 2 3 4) :INITIAL-VALUE 'FOO) => ((((FOO 1) 2) 3) 4)
(REDUCE #'LIST '(1 2 3 4) :FROM-END T :INITIAL-VALUE 'FOO)
=> (1 (2 (3 (4 FOO))))
----------------------------------------------------------------
16. Shall the Bawden/Moon solution to the "invisible block" problem
be accepted? The solution is to define (RETURN x) to mean precisely
(RETURN-FROM NIL x), and to specify that essentially all standard
iterators produce blocks named NIL. A block with a name other than
NIL cannot capture a RETURN, only a RETURN-FROM with a matching name.
(y) yes (n) no
17. Shall the TAGBODY construct be incorporated? This expresses just
the behavior of the GO aspect of a PROG. Any atoms in the body
are not evaluated, but serve as tags that may be specified to GO.
Tags have lexical scope and dynamic extent. TAGBODY always returns NIL.
(y) yes (n) no
18. What shall be done about RESTART? The following alternatives seem to
be the most popular:
(a) Have no RESTART form.
(b) RESTART takes the name of a block. What happens when you say
(RESTART NIL) must be clarified for most iteration constructs.
(c) There is a new binding form called, say, RESTARTABLE.
Within (RESTARTABLE FOO . body), (RESTART FOO) acts as a jump
to the top of the body of the enclosing, matching RESTARTABLE form.
RESTART tags have lexical scope and dynamic extent.
19. Shall there be a built-in identity function, and if so, what shall it
be called?
(c) CR (i) IDENTITY (n) no such function
20. Shall the #*... bit-string syntax replace #"..."? That is, shall what
was before written #"10010" now be written #*10010 ?
(y) yes (n) no
21. Which of the two outstanding array proposals (below) shall be adopted?
(s) the "simple" proposal
(r) the "RPG memorial" proposal
(m) the "simple" proposal as amended by Moon
----------------------------------------------------------------
*********** "Simple" proposal **********
Date: Thursday, 16 September 1982 23:27-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
Here is a revision of my array proposal, fixed up in response to some of
the feedback I've received. See if you like it any better than the
original. In particular, I have explictly indicated that certain
redundant forms such as MAKE-VECTOR should be retained, and I have
removed the :PRINT keyword, since I now believe that it causes more
trouble than it is worth. A revised printing proposal appears at the
end of the document.
Arrays can be 1-D or multi-D. All arrays can be created by MAKE-ARRAY
and can be accessed with AREF. Storage is done via SETF of an AREF.
The term VECTOR refers to any array of exactly one dimension.
Vectors are special, in that they are also sequences, and can be
referenced by ELT. Also, only vectors can have fill pointers.
Vectors can be specialized along several distinct axes. The first is by
the type of the elements, as specified by the :ELEMENT-TYPE keyword to
MAKE-ARRAY. A vector whose element-type is STRING-CHAR is referred to
as a STRING. Strings, when they print, use the "..." syntax; they also
are the legal inputs to a family of string-functions, as defined in the
manual. A vector whose element-type is BIT (alias (MOD 2)), is a
BIT-VECTOR. These are special because they form the set of legal inputs
to the boolean bit-vector functions. (We might also want to print them
in a strange way -- see below.)
Some implementations may provide a special, highly efficient
representation for simple vectors. A simple vector is (of course) 1-D,
cannot have a fill pointer, cannot be displaced, and cannot be altered
in size after its creation. To get a simple vector, you use the :SIMPLE
keyword to MAKE-ARRAY with a non-null value. If there are any
conflicting options specified, an error is signalled. If an
implementation does not support simple vectors, this keyword/value is
ignored except that the error is still signalled on inconsistent cases.
We need a new set of type specifiers for simple things: SIMPLE-VECTOR,
SIMPLE-STRING, and SIMPLE-BIT-VECTOR, with the corresponding
type-predicate functions. Simple vectors are referenced by AREF in the
usual way, but the user may use THE or DECLARE to indicate at
compile-time that the argument is simple, with a corresponding increase
in efficiency. Implementations that do not support simple vectors
ignore the "simple" part of these declarations.
Strings (simple or non-simple) self-eval; all other arrays cause an
error when passed to EVAL. EQUAL descends into strings, but not
into any other arrays. EQUALP descends into arrays of all kinds,
comparing the corresponding elements with EQUALP. EQUALP is false
if the array dimensions are not the same, but it is not sensitive to
the element-type of the array, whether it is simple, etc. In comparing
the dimensions of vectors, EQUALP uses the length from 0 to the fill
pointer; it does not look at any elements beyond the fill pointer.
The set of type-specifiers required for all of this is ARRAY, VECTOR,
STRING, BIT-VECTOR, SIMPLE-VECTOR, SIMPLE-STRING, SIMPLE-BIT-VECTOR.
Each of these has a corresponding type-P predicate, and each can be
specified in list from, along with the element-type and dimension(s).
MAKE-ARRAY takes the following keywords: :ELEMENT-TYPE, :INITIAL-VALUE,
:INITIAL-CONTENTS, :FILL-POINTER, and :SIMPLE. There is still some
discussion as to whether we should retain array displacement, which
requires :DISPLACED-TO and :DISPLACED-INDEX-OFFSET.
The following functions are redundant, but should be retained for
clarity and emphasis in code: MAKE-VECTOR, MAKE-STRING, MAKE-BIT-VECTOR.
MAKE-VECTOR takes the same keywords as MAKE-ARRAY, but can only take a
single integer as the dimension argument. MAKE-STRING and
MAKE-BIT-VECTOR are like MAKE-VECTOR, but do not take the :ELEMENT-TYPE
keyword, since the element-type is implicit. Similarly, we should
retain the forms VREF, CHAR, and BIT, which are identical in operation
to AREF, but which declare their aray argument to be VECTOR, STRING, or
BIT-VECTOR, respectively.
If the :SIMPLE keyword is not specified to MAKE-ARRAY or related forms,
the default is NIL. However, vectors produced by random forms such as
CONCATENATE are simple, and vectors created when the reader sees #(...)
or "..." are also simple.
As a general rule, arrays are printed in a simple format that, upon
being read back in, produces a form that is EQUALP to the original.
However, some information may be lost in the printing process:
element-type restrictions, whether a vector is simple, whether it has a
fill pointer, whether it is displaced, and the identity of any element
that lies beyond the fill pointer. This choice was made to favor ease
of interactive use; if the user really wants to preserve in printed form
some complex data structure containing non-simple arrays, he will have
to develop his own printer.
A switch, SUPPRESS-ARRAY-PRINTING, is provided for users who have lots
of large arrays around and don't want to see them trying to print. If
non-null, this switch causes all arrays except strings to print in a
short, non-readable form that does not include the elements:
#<array-...>. In addition, the printing of arrays and vectors (but not
of strings) is subject to PRINLEVEL and PRINLENGTH.
Strings, simple or otherwise, print using the "..." syntax. Upon
read-in, the "..." syntax creates a simple string.
Bit-vectors, simple or otherwise, print using the #"101010..." syntax.
Upon read-in, this format produces a simple bit-vector. Bit vectors do
observe SUPPRESS-ARRAY-PRINTING.
All other vectors print out using the #(...) syntax, observing
PRINLEVEL, PRINLENGTH, and SUPPRESS-ARRAY-PRINTING. This format reads
in as a simple vector of element-type T.
All other arrays print out using the syntax #nA(...), where n is the
number of dimensions and the list is a nest of sublists n levels deep,
with the array elements at the deepest level. This form observes
PRINLEVEL, PRINLENGTH, and SUPPRESS-ARRAY-PRINTING. This format reads
in as an array of element-type T.
Query: I am still a bit uneasy about the funny string-like syntax for
bit vectors. Clearly we need some way to read these in that does not
turn into a type-T vector. An alternative might be to allow #(...) to
be a vector of element-type T, as it is now, but to take the #n(...)
syntax to mean a vector of element-type (MOD n). A bit-vector would
then be #2(1 0 1 0...) and we would have a parallel notation available
for byte vectors, 32-bit word vectors, etc. The use of the #n(...)
syntax to indicate the length of the vector always struck me as a bit
useless anyway. One flaw in this scheme is that it does not extend to
multi-D arrays. Before someone suggests it, let me say that I don't
like #nAm(...), where n is the rank and m is the element-type -- it
would be too hard to remember which number was which. But even with
this flaw, the #n(...) syntax might be useful.
********** "RPG memorial" proposal **********
Date: Thursday, 23 September 1982 00:38-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
Several people have stated that they dislike my earlier proposal because
it uses the good names (VECTOR, STRING, BIT-VECTOR, VREF, CHAR, BIT) on
general 1-D arrays, and makes the user say "simple" when he wants one of
the more specialized high-efficiency versions. This makes extra work
for users, who will want simple vectors at least 95% of the time. In
addition, there is the argument that simple vectors should be thought of
as a first-class data-type (in implementations that provide them) and
not as a mere degenerate form of array.
Just to see what it looks like, I have re-worked the earlier proposal to
give the good names to the simple forms. This does not really eliminate
any of the classes in the earlier proposal, since each of those classes
had some attributes or operations that distinguished it from the others.
Since there are getting to be a lot of proposals around, we need some
nomencalture for future discussions. My first attempt, with the
user-settable :PRINT option should be called the "print-switch"
proposal; the next one, with the heavy use of the :SIMPLE switch should
be the "simple-switch" proposal; this one can be called the "RPG
memorial" proposal. Let me know what you think about this vs. the
simple-switch version -- I can live with either, but I really would like
to nail this down pretty soon so that we can get on with the
implementation.
Arrays can be 1-D or multi-D. All arrays can be created by MAKE-ARRAY
and can be accessed with AREF. Storage is done via SETF of an AREF.
1-D arrays are special, in that they are also of type SEQUENCE, and can
be referenced by ELT. Also, only 1-D arrays can have fill pointers.
Some implementations may provide a special, highly efficient
representation for simple 1-D arrays, which will be of type VECTOR. A
vector is 1-dimensional, cannot have a fill pointer, cannot be
displaced, and cannot be altered in size after its creation. To get a
vector, you use the :VECTOR keyword to MAKE-ARRAY with a non-null value.
If there are any conflicting options specified, an error is signalled.
The MAKE-VECTOR form is equivalent to MAKE-ARRAY with :VECTOR T.
A STRING is a VECTOR whose element-type (specified by the :ELEMENT-TYPE
keyword) is STRING-CHAR. Strings are special in that they print using
the "..." syntax, and they are legal inputs to a class of "string
functions". Actually, these functions accept any 1-D array whose
element type is STRING-CHAR. This more general class is called a
CHAR-SEQUENCE.
A BIT-VECTOR is a VECTOR whose element-type is BIT, alias (MOD 2).
Bit-vectors are special in that they print using the #*... syntax, and
they are legal inputs to a class of boolean bit-vector functions.
Actually, these functions accept any 1-D array whose element-type is
BIT. This more general class is called a BIT-SEQUENCE.
All arrays can be referenced via AREF, but in some implementations
additional efficiency can be obtained by declaring certain objects to be
vectors, strings, or bit-vectors. This can be done by normal
type-declarations or by special accessing forms. The form (VREF v n) is
equivalent to (AREF (THE VECTOR v) n). The form (CHAR s n) is
equivalent to (AREF (THE STRING s) n). The form (BIT b n) is equivalent
to (AREF (THE BIT-VECTOR b) n).
If an implementation does not support vectors, the :VECTOR keyword is
ignored except that the error is still signalled on inconsistent cases;
The additional restrictions on vectors are not enforced. MAKE-VECTOR is
treated just like the equivalent make-array. VECTORP is true of every
1-D array, STRINGP of every CHAR-SEQUENCE, and BIT-VECTOR of every
BIT-SEQUENCE.
CHAR-SEQUENCEs, including strings, self-eval; all other arrays cause an
error when passed to EVAL. EQUAL descends into CHAR-SEQUENCEs, but not into
any other arrays. EQUALP descends into arrays of all kinds, comparing
the corresponding elements with EQUALP. EQUALP is false if the array
dimensions are not the same, but it is not sensitive to the element-type
of the array, whether it is a vector, etc. In comparing the dimensions of
vectors, EQUALP uses the length from 0 to the fill pointer; it does not
look at any elements beyond the fill pointer.
The set of type-specifiers required for all of this is ARRAY, VECTOR,
STRING, BIT-VECTOR, SEQUENCE, CHAR-SEQUENCE, and BIT-SEQUENCE.
Each of these has a corresponding type-P predicate, and each can be
specified in list from, along with the element-type and dimension(s).
MAKE-ARRAY takes the following keywords: :ELEMENT-TYPE, :INITIAL-VALUE,
:INITIAL-CONTENTS, :FILL-POINTER, :DISPLACED-TO, :DISPLACED-INDEX-OFFSET,
and :VECTOR.
The following functions are redundant, but should be retained for
clarity and emphasis in code: MAKE-VECTOR, MAKE-STRING, MAKE-BIT-VECTOR.
MAKE-VECTOR takes a single length argument, along with :ELEMENT-TYPE,
:INITIAL-VALUE, and :INITIAL-CONTENTS. MAKE-STRING and MAKE-BIT-VECTOR
are like MAKE-VECTOR, but do not take the :ELEMENT-TYPE keyword, since
the element-type is implicit.
If the :VECTOR keyword is not specified to MAKE-ARRAY or related forms,
the default is NIL. However, sequences produced by random forms such as
CONCATENATE are vectors.
Strings always are printed using the "..." syntax. Bit-vectors always
are printed using the #*... syntax. Other vectors always print using
the #(...) syntax. Note that in the latter case, any element-type
restriction is lost upon readin, since this form always produces a
vector of type T when it is read. However, the new vector will be
EQUALP to the old one. The #(...) syntax observes PRINLEVEL,
PRINLENGTH, and SUPPRESS-ARRAY-PRINTING. The latter switch, if non-NIL,
causes the array to print in a non-readable form: #<ARRAY...>.
CHAR-SEQUENCEs print out as though they were strings, using the "..."
syntax. BIT-SEQUENCES print out as BIT-STRINGS, using the #*... syntax.
All other arrays print out using the #nA(...) syntax, where n is the
number of dimensions and the list is actually a list of lists of lists,
nested n levels deep. The array elements appear at the lowest level.
The #A syntax also observes PRINLEVEL, PRINLENGTH, and
SUPPRESS-ARRAY-PRINTING. The #A format reads in as a non-displaced
array of element-type T.
Note that when an array is printed and read back in, the new version is
EQUALP to the original, but some information about the original is lost:
whether the original was a vector or not, element type restrictions,
whether the array was displaced, whether there was a fill pointer, and
the identity of any elements beyond the fill-pointer. This choice was
made to favor ease of interactive use; if the user really wants to
preserve in printed form some complex data structure containing more
complex arrays, he will have to develop his own print format and printer.
********** Moon revision of "simple" proposal **********
Date: Thursday, 30 September 1982 01:59-EDT
From: MOON at SCRC-TENEX
I prefer the "simple switch" to the "RPG memorial" proposal, with one
modification to be found below. The reason for this preference is that
it makes the "good" name, STRING for example, refer to the general class
of objects, relegating the efficiency decision to a modifier ("simple").
The alternative makes the efficiency issue too visible to the casual user,
in my opinion. You have to always be thinking "do I only want this to
work for efficient strings, which are called strings, or should it work
for all kinds of strings, which are called arrays of characters?".
Better to say, "well this works for strings, and hmm, is it worth
restricting it to simple-strings to squeeze out maximal efficiency"?
Lest this seem like I am trying to sabotage the efficiency of Lisp
implementations that are stuck with "stock" hardware, consider the
following:
In the simple switch proposal, how is (MAKE-ARRAY 100) different from
(MAKE-ARRAY 100 :SIMPLE T)? In fact, there is only one difference--it is
an error to use ADJUST-ARRAY-SIZE on the latter array, but not on the
former. Except for this, simpleness consists, simply, of the absence of
options. This suggests to me that the :SIMPLE option be flushed, and
instead a :ADJUSTABLE-SIZE option be added (see, I pronounce the colons).
Even on the Lisp machine, where :ADJUSTABLE-SIZE makes no difference, I
think it would be an improvement, merely for documentation purposes. Now
everything makes sense: if you don't ask for any special features in your
arrays, you get simple ones, which is consistent with the behavior of the
sequence functions returning simple arrays always. And if some
implementation decides they need the sequence functions to return
non-simple arrays, they can always add additional keywords to them to so
specify. The only time you need to know about the word "simple" at all is
if you are making type declarations for efficiency, in which case you have
to decide whether to declare something to be a STRING or a SIMPLE-STRING.
And it makes sense that the more restrictive declaration be a longer word.
This also meets RPG's objection, which I think boils down to the fact
that he thought it was stupid to have :SIMPLE T all over his programs.
He was right.
I'm fairly sure that I don't understand the portability issues that KMP
brought up (I don't have a whole lot of time to devote to this). But I
think that in my proposal STRINGP and SIMPLE-STRINGP are never the same
in any implementation; for instance, in the Lisp machine STRINGP is true
of all strings, while SIMPLE-STRINGP is only true of those that do not
have fill-pointers. If we want to legislate that the :ADJUSTABLE-SIZE
option is guaranteed to turn off SIMPLE-STRINGP, I expect I can dig up
a bit somewhere to remember the value of the option. This would in fact
mean that simple-ness is a completely implementation-independent concept,
and the only implementation-dependence is how much (if any) efficiency
you gain by using it, and how much of that efficiency you get for free
and how much you get only if you make declarations.
Perhaps the last sentence isn't obvious to everyone. On the LM-2 Lisp
machine, a simple string is faster than a non-simple string for many
operations. This speed-up happens regardless of declarations; it is a
result of a run-time dispatch to either fast microcode or slow microcode.
On the VAX with a dumb compiler and no tuning, a simple string is only
faster if you make declarations. On the VAX with a dumb compiler but some
obvious tuning of sequence and string primitives to move type checks out of
inner loops (making multiple copies of the inner loop), simple strings are
faster for these operations, but still slow for AREF unless you make a type
declaration. On the VAX with a medium-smart compiler that does the same
sort of tuning on user functions, simple strings are faster for user
functions, too, if you only declare (OPTIMIZE SPEED) [assuming that the
compiler prefers space over speed by default, which is the right choice in
most implementations], and save space as well as time if you go whole hog
and make a type declaration. On the 3600 Lisp machine, you have sort of a
combination of the first case and the last case.
I also support the #* syntax for bit vectors, rather than the #" syntax.
It's probably mere temporal accident that the simple switch proposal
uses #" while the RPG memorial proposal uses #*.
To sum up:
A vector is a 1-dimensional array. It prints as #(foo bar) or #<array...>
depending on the value of a switch.
A string is a vector of characters. It always prints as "foo". Unlike
all other arrays, strings self-evaluate and are compared by EQUAL.
A bit-vector is a vector of bits. It always prints as #*101. Since as
far as I can tell these are redundant with integers, perhaps like integers
they should self-evaluate and be compared by EQUAL. I don't care.
A simple-vector, simple-string, or simple-bit-vector is one of the above
with none of the following MAKE-ARRAY (or MAKE-STRING) options specified:
:FILL-POINTER
:ADJUSTABLE-SIZE
:DISPLACED-TO
:LEADER-LENGTH, :LEADER-LIST (in implementations that offer them)
There are type names and predicates for the three simple array types. In
some implementations using the type declaration gets you more efficient
code that only works for that simple type, which is why these are in the
language at all. There are no user-visible distinctions associated with
simpleness other than those implied by the absence of the above MAKE-ARRAY
options.
----------------------------------------------------------------
22. Shall the following proposal for the OPTIMIZE declaration be adopted?
(y) yes (n) no
----------------------------------------------------------------
Date: Wednesday, 15 September 1982 20:51-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
At the meeting I volunteered to produce a new proposal for the OPTIMIZE
declaration. Actually, I sent out such a proposal a couple of weeks
ago, but somehow it got lost before reaching SU-AI -- both that machine
and CMUC have been pretty flaky lately. I did not realize that the rest
of you had not seen this proposal until a couple of days ago.
Naturally, this is the one thing I did not keep a copy of, so here is my
reconstruction. I should say that this proposal is pretty ugly, but it
is the best that I've been able to come up with. If anyone out there
can do better, feel free.
Guy originally proposed a format like (DECLARE (OPTIMIZE q1 q2 q3)),
where each of the q's is a quality from the set {SIZE, SPEED, SAFETY}.
(He later suggested to me that COMPILATION-SPEED would be a useful
fourth quality.) The ordering of the qualities tells the system which
to optimize for. The obvious problem is that you sometimes want to go
for, say, SPEED above all else, but usually you want some level of
compromise. There is no way in this scheme to specify how strongly the
system should favor one quality over another. We don't need a lot of
gradations for most compilers, but the simple ordering is not expressive
enough.
One possibility is to simply reserve the OPTIMIZE declaration for the
various implementations, but not to specify what is done with it. Then
the implementor could specify in the red pages whatever declaration
scheme his compiler wants to follow. Unfortunately, this means that
such declarations would be of no use when the code is ported to another
Common Lisp, and users would have no portable way to flag that some
function is an inner loop and should be super-fast, or whatever. The
proposal below tries to provide a crude but adequate optimization
declaration for portable code, while still making it possible for users
to fine-tune the compiler's actions for particular implementations.
What I propose is (DECLARE (OPTIMIZE (qual1 value1) (qual2 value2) ...),
where the qualities are the four mentioned above and each is paired with
a value from 0 to 3 inclusive. The ordering of the clauses doesn't
matter, and any quality not specified gets a default value of 1. The
intent is that {1, 1, 1, 1} would be the compiler's normal default --
whatever set of compromises the implementor believes is appropriate for
his user community. A setting of 0 for some value is an indication that
the associated quality is unimportant in this context and may be
discrimintaed against freely. A setting of 2 indicates that the quality
should be favored more than normal, and a setting of 3 means to go all
out to favor that quality. Only one quality should be raised above 1 at
any one time.
The above specification scheme is crude, but sufficiently expressive for
most needs in portable code. A compiler implementor will have specific
decisions to make -- whether to suppress inline expansions, whether to
type-check the arguments to CAR and CDR, whether to check for overflow
on arithmetic declared to be FIXNUM, whether to run the peephole
optimizer, etc. -- and it is up to him to decide how to tie these
decisions to the above values so as to match the users expressed wishes.
These decision criteria should be spelled out in that implementation's red
pages. For example, it might be the case that the peephole optimizer is
not run if COMPILER-SPEED > 1, that type checking for the argument to
CAR and CDR is suppressed if SPEED > SAFETY+1, etc.
----------------------------------------------------------------
23. Shall it be permitted for macros calls to expand into DECLARE forms
and then be recognized as valid declarations? For example:
(DEFMACRO CUBOIDS (&REST VARS)
`(DECLARE (TYPE (ARRAY SHORT-FLONUM 3) ,@VARS)
(SPECIAL ,@VARS)
(OPTIMIZE SPEED)
(INLINE HACK-CUBOIDS)))
(DEFUN CUBOID-EXPERT (A B C D)
(CUBOIDS A C)
...)
This would not allows macros calls *within* a DECLARE form, only allow
macros to expand into a DECLARE form.
(y) yes (n) no
24. Shall there be printer control variables ARRAY-PRINLEVEL and
ARRAY-PRINLENGTH to control printing of arrays? These would not
limit the printing of strings.
(y) yes (n) no
25. Shall lambda macros, as described below, be incorporated into
the language, and if so, shall they occupy the function name space
or a separate name space?
(f) function name space (s) separate name space (n) no lambda macros
----------------------------------------------------------------
Date: Wednesday, 22 September 1982, 02:27-EDT
From: Howard I. Cannon <HIC at SCRC-TENEX at MIT-MC>
This is the documentation I wrote for lambda-macros as I implemented
them on the Lisp Machine. Please consider this a proposed definition.
Lambda macros may appear in functions where LAMBDA would have previously
appeared. When the compiler or interpreter detects a function whose CAR
is a lambda macro, they "expand" the macro in much the same way that
ordinary Lisp macros are expanded -- the lambda macro is called with the
function as its argument, and is expected to return another function as
its value. Lambda macros may be accessed with the (ε3:lambda-macroε*
ε2nameε*) function specifier.
defspec lambda-macro function-spec lambda-list &body body
Analagously with ε3macroε*, defines a lambda macro to be called
ε2function-specε*. ε2lambda-listε* should consist of one variable, which
will be the function that caused the lambda macro to be called. The
lambda macro must return a function. For example:
lisp
(lambda-macro ilisp (x)
`(lambda (&optional ,@(second x) &rest ignore) . ,(cddr x)))
end←lisp
would define a lambda macro called ε3ilispε* which would cause the
function to accept arguments like a standard Interlisp function -- all
arguments are optional, and extra arguments are ignored. A typical call
would be:
lisp
(fun-with-functional-arg #'(ilisp (x y z) (list x y z)))
end←lisp
Then, any calls to the functional argument that
ε3fun-with-functional-argε* executes will pass arguments as if the
number of arguments did not matter.
end←defspec
defspec deflambda-macro
ε3deflambda-macroε* is like ε3defmacroε*, but defines a lambda macro
instead of a normal macro.
end←defspec
defspec deflambda-macro-displace
ε3deflambda-macro-displaceε* is like ε3defmacro-displaceε*, but defines
a lambda macro instead of a normal macro.
end←defspec
defspec deffunction function-spec lambda-macro-name lambda-list &body body
ε3deffunctionε* defines a function with an arbitrary lambda macro
instead of ε3lambdaε*. It takes arguments like ε3defunε*, expect that
the argument immediatly following the function specifier is the name of
the lambda macro to be used. ε3deffunctionε* expands the lambda macro
immediatly, so the lambda macro must have been previously defined.
For example:
lisp
(deffunction some-interlisp-like-function ilisp (x y z)
(list x y z))
end←lisp
would define a function called ε3some-interlisp-like-functionε*, that
would use the lambda macro called ε3ilispε*. Thus, the function would
do no number of arguments checking.
end←defspec
----------------------------------------------------------------
26. Shall the floating-point manipulations described below be adopted?
(y) as described by MOON
(a) as amended (FLOAT-SIGN changed) by GLS
(n) do not adopt them
----------------------------------------------------------------
Date: Thursday, 30 September 1982 05:55-EDT
From: MOON at SCRC-TENEX
I am not completely happy with the FLOAT-FRACTION, FLOAT-EXPONENT, and
SCALE-FLOAT functions in the Colander edition. At the meeting in August I
was assigned to make a proposal. I am slow.
A minor issue is that the range of FLOAT-FRACTION fails to include zero (of
course it has to), and is inclusive at both ends, which means that there
are two possible return values for some numbers. I guess that this ugliness
has to stay because some implementations require this freedom for hardware
reasons, and it doesn't make a big difference from a numerical analysis point
of view. My proposal is to include zero in the range and to add a note about
two possible values for numbers that are an exact power of the base.
A more major issue is that some applications that break down a flonum into
a fraction and an exponent, or assemble a flonum from a fraction and an
exponent, are best served by representing the fraction as a flonum, while
others are best served by representing it as an integer. An example of
the former is a numerical routine that scales its argument into a certain
range. An example of the latter is a printing routine that must do exact
integer arithmetic on the fraction.
In the agenda for the August meeting it was also proposed that there be
a function to return the precision of the representation of a given flonum
(presumably in bits); this would be in addition to the "epsilon" constants
described on page 143 of the Colander.
A goal of all this is to make it possible to write portable numeric functions,
such as the trigonometric functions and my debugged version of Steele's
totally accurate floating-point number printer. These would be portable
to all implementations but perhaps not as efficient as hand-crafted routines
that avoided bignum arithmetic, used special machine instructions, avoided
computing to more precision than the machine really has, etc.
Proposal:
SCALE-FLOAT x e -> y
y = (* x (expt 2.0 e)) and is a float of the same type as x.
SCALE-FLOAT is more efficient than exponentiating and multiplying, and
also cannot overflow or underflow unless the final result (y) cannot
be represented.
x is also allowed to be a rational, in which case y is of the default
type (same as the FLOAT function).
[x being allowed to be a rational can be removed if anyone objects. But
note that this function has to be generic across the different float types
in any case, so it might as well be generic across all number types.]
UNSCALE-FLOAT y -> x e
The first value, x, is a float of the same type as y. The second value, e,
is an integer such that (= y (* x (expt 2.0 e))).
The magnitude of x is zero or between 1/b and 1 inclusive, where b is the
radix of the representation: 2 on most machines, but examples of 8 and
16, and I think 4, exist. x has the same sign as y.
It is an error if y is a rational rather than a float, or if y is an
infinity. (Leave infinity out of the Common Lisp manual, though).
It is not an error if y is zero.
FLOAT-MANTISSA x -> f
FLOAT-EXPONENT x -> e
FLOAT-SIGN x -> s
FLOAT-PRECISION x -> p
f is a non-negative integer, e is an integer, s is 1 or 0.
(= x (* (SCALE-FLOAT (FLOAT f x) e) (IF (ZEROP S) 1 -1))) is true.
It is up to the implementation whether f is the smallest possible integer
(zeros on the right are removed and e is increased), or f is an integer with
as many bits as the precision of the representation of x, or perhaps a "few"
more. The only thing guaranteed about f is that it is non-negative and
the above equality is true.
f is non-negative to avoid problems with minus zero. s is 1 for minus zero
even though MINUSP is not true of minus zero (otherwise the FLOAT-SIGN function
would be redundant).
p is an integer, the number of bits of precision in x. This is a constant
for each flonum representation type (except perhaps for variable-precision
"bigfloats").
[I am amenable to converting these four functions into one function that
returns four values if anyone can come up with a name. EXPLODE-FLOAT is
the best so far, and it's not very good, especially since the traditional
EXPLODE function has been flushed from Common Lisp. Perhaps DECODE-FLOAT.]
[I am amenable to adding a function that takes f, e, and s as arguments
and returns x. It might be called ENCODE-FLOAT or MAKE-FLOAT. It ought to
take either a type argument or an optional fourth argument, the way FLOAT
takes an optional second argument, which is an example of the type to return.]
FTRUNC x -> fp ip
The FTRUNC function as it is already defined provides the fraction-part and
integer-part operations.
These functions exist now in the Lisp machines, with different names and slightly
different semantics in some cases. They are very easy to write.
Comments? Suggestions for names?
Date: 4 October 1982 2355-EDT (Monday)
From: Guy.Steele at CMU-10A
I support Moon's proposal, but would like to suggest that FLOAT-SIGN
be modified to
(FLOAT-SIGN x &optional (y (float 1 x)))
returns z such that x and z have same sign and (= (abs y) (abs z)).
In this way (FLOAT-SIGN x) returns 1.0 or -1.0 of the same format as x,
and FLOAT-SIGN of two arguments is what the IEEE proposal calls COPYSIGN,
a useful function indeed in numerical code.
--Guy
----------------------------------------------------------------
27. Shall DEFMACRO, DEFSTRUCT, and other defining forms also be
allowed to take documentation strings as possible and appropriate?
(y) yes (n) no
28. Shall the following proposed revision of OPEN keywords be accepted?
(y) yes (n) no
----------------------------------------------------------------
Date: Monday, 4 October 1982, 17:08-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
OPEN takes a filename as its first argument. The rest of its arguments
are keyword/value pairs.
WITH-OPEN-STREAM's first subform is a list of a variable (to be bound to
a stream), a filename, and the rest of the elements are keyword/value
pairs.
The keywords are as follows, with their possible values and defaults:
:DIRECTION :INPUT (the default), :OUTPUT, :APPEND, :OVERWRITE, :PROBE
:INPUT - The file is expected to exist. Output operations are not allowed.
:OUTPUT - The file is expected to not exist. A new file is created. Input
operations are not allowed.
:APPEND - The file is expected to exist. Input operations are not allowed.
New characters are appened to the end of the existing file.
:OVERWRITE - The file is expected to exist. All operations are allowed.
The "file pointer" starts at the beginning of the file.
:PROBE - The file may or may not exist. Neither input nor output operations
are allowed. Furthermore, it is not necessary to close the stream.
:CHARACTERS T (the default), NIL, :DEFAULT
T - Open the file for reading/writing of characters.
NIL - Open the file for reading/writing of bytes (non-negative integers).
:DEFAULT - Let the file system decide, based on the file it finds.
:BYTE-SIZE a fixnum or :DEFAULT (the default)
a fixnum - Use this byte size.
:DEFAULT - Let the file system decide, based on the file it finds.
:IF-EXISTS :ERROR (the default), :NEW-VERSION, :RENAME,
:RENAME-AND-DELETE, :OVERWRITE, :APPEND, :REPLACE
Ignored if direction is not :OUTPUT. This tells what to do if the file
that you're trying to create already exists.
:ERROR - Signal an error.
:NEW-VERSION - Create a file with the same filename except with "latest" version.
:RENAME - Rename the existing file to something else and proceed.
:RENAME-AND-DELETE - Rename the existing file and delete (but don't expunge,
if your system has undeletion) it, and proceed.
:OVERWRITE - Open for :OVERWRITE instead. (If your file system doesn't have
this, use :RENAME-AND-DELETE if you have undeletion and :RENAME otherwise.)
:APPEND - Open for :APPEND instead.
:REPLACE - Replace the existing file, deleting it when the stream is closed.
:IF-DOES-NOT-EXIST :ERROR (the default), :CREATE
Ignored if direction is neither :APPEND nor :OVERWRITE
:ERROR - Signal an error.
:CREATE - Create the file and proceed.
Notes:
I renamed :READ-ALTER to :OVERWRITE; :READ-WRITE might also be good.
The :DEFAULT values are very useful, although some systems cannot figure
out this information. :CHARACTERS :DEFAULT is especially useful for
LOAD. Having the byte size come from the file only when the option is
missing, as the latest Common Lisp manual says, is undesirable because
it makes things harder for programs that are passing the value of that
keyword argument as computed from an expression.
Example of OPEN:
(OPEN "f:>dlw>lispm.init" :DIRECTION :OUTPUT)
Example of WITH-OPEN-FILE:
(WITH-OPEN-FILE (STREAM "f:>dlw>lispm.init" :DIRECTION :OUTPUT) ...)
OPEN can be kept Maclisp compatible by recognizing whether the second
argument is a list or not. Lisp Machine Lisp does this for the benefit
of old programs. The new syntax cannot be mistaken for the old one.
I removed :ECHO because we got rid of MAKE-ECHO-STREAM at the last
meeting.
Other options that the Lisp Machine will probably have, and which might
be candidates for Common Lisp, are: :INHIBIT-LINKS, :DELETED,
:PRESERVE-DATES, and :ESTIMATED-SIZE.
----------------------------------------------------------------
-------
∂05-Oct-82 0533 ZVONA at MIT-MC /BALLOT/
Date: Tuesday, 5 October 1982 08:32-EDT
Sender: ZVONA at MIT-OZ
From: ZVONA at MIT-MC
To: Guy.STEELE at CMU-20C
Cc: b.steele at CMU-10A, common-lisp at SU-AI
Subject: /BALLOT/
~xxxxxnxxxxxxxxxxxxxxxxxxxxxx
Explanation:
Dick Waters' LetS, which he will release imminently, is far superior
to LOOP. Unlike LOOP, which is basically a hack, it is based on a
strong theory of what loops really are and what their structure is.
Basically it is a compiler which takes code written in terms of
streams and compiles it into efficient iterative code.
I'm not involved in common lisp. I probably don't get a vote, but
this is one I really care about.
-------
∂05-Oct-82 1002 Guy.Steele at CMU-10A Addendum to voting procedure
Date: 5 October 1982 1257-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Addendum to voting procedure
I forgot to provide a way to indicate "no vote" on a question.
Use "-" for this purpose. So a response might look like:
~ xabyb n-xxb arn-- --ax- xxa-- -x-
Second, I want to emphasize again that this ballot, as with all
previous ballots, is not necessarily a majority-rules vote,
but an attempt to determine for each question whether there is
a general consensus or not. If there is consensus, I take that
as a mandate to edit the document accordingly; if not, the
question remains open for discussion.
--Guy
∂05-Oct-82 1517 Scott E. Fahlman <Fahlman at Cmu-20c> /BALLOT/
Date: Tuesday, 5 October 1982 18:16-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: steele at CMU-20C
Cc: common-lisp at SU-AI
Subject: /BALLOT/
~ b n n y y n y y y y y y n y y y y a i y m y y n n a y y
1 3 1 - 3 * 1 2 - 1 * 2 2 2 1 2 2 * 3 2 2 - 1 1 * 1 2 - Intensity
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 Issue #
I have included an indication of how much I care about each issue in a
way that I hope will not choke Guy's voting machine. 1 means that I
will happily abide by the will of the majority; 2 means that I have a
definite preference; 3 means that this issue is very important to me; 4
means that this is a non-negotiable issue. (There are no 4's here.)
- means that there is no other choice presented, and the one that is
presented seems OK. A * means "see below". The numbers on the third line
are just index numbers so that I can see what I'm doing.
6: I am in favor of adding the LOOP package as described (once it is
completed) to the language as a portable yellow pages module. I feel
rather strongly that it is premature to add LOOP to the white pages.
11: Whatever is done about global vars, global constants should be the
same. I oppose option 3 or any plan to make them look syntactically
different.
18. I now believe that RESTART is more trouble than it is worth. I am
strongly opposed to any plan, such as option 3, that would add a RESTART
form but make it impossible to use this with the implicit block around a
DEFUN. If you have to introduce a RESTARTABLE block, you may as
well use PROG/GO.
25: I seem to be unable to locate any explanation of why Lambda macros
are useful enough to be worth the bother. Looks like needless hair to
me, but I seem to dimly recall some arguments for why they were needed.
I'm not passionately opposed, but every page full of hairy stuff in the
manual hurts us.
∂05-Oct-82 1532 Dave Dyer <DDYER at USC-ISIB> comment on lambda macros
Date: 5 Oct 1982 1530-PDT
From: Dave Dyer <DDYER at USC-ISIB>
Subject: comment on lambda macros
To: Fahlman at CMU-20C
cc: common-lisp at SU-AI
In-Reply-To: Your message of Tuesday, 5 October 1982 18:16-EDT
LAMBDA macros in zetalisp were borrowed from Interlisp to make it
possible to extend lambda-expression syntax to accomodate Interlisp
semantics. In general, LAMBDA macros allow an arbitrary translation
step before application of a function. Very useful for embedded languages.
There is no hair, just a few simple taps before errors are declared.
-------
∂05-Oct-82 1552 Earl A. Killian <EAK at MIT-MC> defun semantics
Date: 5 October 1982 18:51-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: defun semantics
To: common-lisp at SU-AI
Does defun add the function name to the lexical environment of
the body? Should it?
For example, in
(defun revappend (a b)
(if (null a)
b
(revappend (cdr a) (cons (car a) b))))
is the tail recursion implementable as a simple GO, or must the
system consult the function cell of the symbol REVAPPEND? I vote
for allowing the GO, i.e. adding REVAPPEND to the lexical
function environment, in effect, defining DEFUN in terms of
LABELS instead of LAMBDA.
∂05-Oct-82 1612 Brian G. Milnes <Milnes at CMU-20C> /BALLOT/
Date: Tuesday, 5 October 1982 19:11-EDT
From: Brian G. Milnes <Milnes at CMU-20C>
To: STEELE at CMU-20C
Cc: b.steele at CMU-10A, common-lisp at SU-AI
Subject: /BALLOT/
12345678912345678912345678
~ayxyyynyynnyyxyxxiymyysyyx
∂05-Oct-82 1625 Earl A. Killian <EAK at MIT-MC> arrays
Date: 5 October 1982 19:24-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: arrays
To: common-lisp at SU-AI
Suggestion: Now that :TYPE to MAKE-ARRAY is :ELEMENT-TYPE,
shouldn't ARRAY-TYPE be ARRAY-ELEMENT-TYPE? Or perhaps just
ELEMENT-TYPE, in which case it would work for any sequence? Not
clear that the concept is very useful for generalized sequences
(e.g. ELEMENT-TYPE of a cons would always be T), though it might
find some use in writing new sequence functions.
Question 1: was ARRAY-RESET-FILL-POINTER eliminated by the decision
at the last meeting to use SETF exclusively? I.e. is it subsumed
by (SETF (ARRAY-ACTIVE-LENGTH A) L)?
Question 2: I'm not sure what resulted from the displaced array
discussion. My memory tells me that every proposed use of
displaced arrays was countered with an appropriate access
function. Has anyone a proposed set of new access functions?
Or are even these deemed unnecessary?
∂05-Oct-82 1927 Alan Bawden <ALAN at MIT-MC> ZVONA: ~xxxxxnxxxxxxxxxxxxxxxxxxxxxx
Date: 5 October 1982 22:18-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ZVONA: ~xxxxxnxxxxxxxxxxxxxxxxxxxxxx
To: ZVONA at MIT-MC
cc: common-lisp at SU-AI
Date: Tuesday, 5 October 1982 08:32-EDT
From: ZVONA
~xxxxxnxxxxxxxxxxxxxxxxxxxxxx
Explanation:
Dick Waters' LetS, which he will release imminently, is far superior
to LOOP. Unlike LOOP, which is basically a hack, it is based on a
strong theory of what loops really are and what their structure is.
Basically it is a compiler which takes code written in terms of
streams and compiles it into efficient iterative code.
Well I think we should flush DO from Common Lisp because in spite of its
utility, it is not "based on a strong theory of what loops really are".
Seriously, I doubt very much that LetS will totally replace LOOP among the
tools I use any more than LOOP replaced DO. I am sick to death of knee-jerk
anti-LOOPism and I am beginning to irrationally regard it as a plot to disable
me as a programmer by excommunicating my most useful tools.
∂05-Oct-82 2032 Masinter at PARC-MAXC Re: keyword pairs and OPEN
Date: 5-Oct-82 20:31:36 PDT (Tuesday)
From: Masinter at PARC-MAXC
Subject: Re: keyword pairs and OPEN
In-reply-to: dlw at SCRC-TENEX's message of Monday, 4 October 1982, 17:08-EDT
To: common-lisp at SU-AI
Is the :DIRECTION :PROBE a proper function of "OPEN"? It seems semantically
quite different; e.g., :BYTE-SIZE, :CHARACTERS etc seem pretty meaningless.
Tenex/Tops-20 allows for "give me name of new file"; is that generally useful?
Interlisp separates out the "direction" (ACCESS method) from the "recognition mode" in its OPENFILE. (The Interlisp VM is the best description of OPENFILE). Thus,
an alternative to consider would have key words:
:ACCESS - one of :INPUT, :OUTPUT, :APPEND (or ...)
no default
:RECOG - one of :OLD, :NEW, :OLD/NEW (or ...)
default depends on :ACCESS
:TYPE - one of :TEXT or :BINARY or :DEFAULT (or ...)
(default :TEXT)
:BYTE-SIZE (only meaningful and implies :TYPE :BINARY)
I'd then fold in the :IF-EXISTS and :IF-DOES-NOT-EXIST with different
recognition modes.
What most people then want is some notion of a search-path algorithm on
recognition mode :INPUT. This sometimes takes the form of hacking with
the name which is supplied, which perhaps Common Lisp should avoid.
∂05-Oct-82 2317 David A. Moon <Moon at SCRC-TENEX at MIT-MC> arrays
Date: Wednesday, 6 October 1982, 01:55-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: arrays
To: common-lisp at SU-AI
In-reply-to: The message of 5 Oct 82 19:24-EDT from Earl A. Killian <EAK at MIT-MC>
Date: 5 October 1982 19:24-EDT
From: Earl A. Killian <EAK at MIT-MC>
Suggestion: Now that :TYPE to MAKE-ARRAY is :ELEMENT-TYPE,
shouldn't ARRAY-TYPE be ARRAY-ELEMENT-TYPE?
Yes, definitely.
Or perhaps just
ELEMENT-TYPE, in which case it would work for any sequence? Not
clear that the concept is very useful for generalized sequences
(e.g. ELEMENT-TYPE of a cons would always be T), though it might
find some use in writing new sequence functions.
Probably this is too random, although I wouldn't mind it.
Question 1: was ARRAY-RESET-FILL-POINTER eliminated by the decision
at the last meeting to use SETF exclusively? I.e. is it subsumed
by (SETF (ARRAY-ACTIVE-LENGTH A) L)?
(SETF (FILL-POINTER surely.
∂06-Oct-82 0106 David A. Moon <Moon at SCRC-TENEX at MIT-MC> Re: keyword pairs and OPEN
Date: Wednesday, 6 October 1982, 04:03-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Re: keyword pairs and OPEN
To: common-lisp at SU-AI
In-reply-to: The message of 5 Oct 82 23:31-EDT from Masinter at PARC-MAXC
Date: 5-Oct-82 20:31:36 PDT (Tuesday)
From: Masinter at PARC-MAXC
Is the :DIRECTION :PROBE a proper function of "OPEN"? It seems semantically
quite different; e.g., :BYTE-SIZE, :CHARACTERS etc seem pretty meaningless.
Well, this is a debatable point. In terms of message passing, a probe stream
has about half the messages that a real-open stream does, and doesn't have any
messages that a real-open stream does not have. These messages are operations
such as getting and setting attributes of the file. So you it's reasonable to
think of probing as a subset of opening, or as a separate function. The Lisp
machine happened to choose the former.
Tenex/Tops-20 allows for "give me name of new file"; is that generally useful?
Without actually creating it, how could it be? If someone else does the same
thing they'll get the same name. If it does actually create it, is this different
in any way from opening in OUTPUT direction?
Interlisp separates out the "direction" (ACCESS method) from the
"recognition mode" in its OPENFILE. (The Interlisp VM is the best
description of OPENFILE). Thus, an alternative to consider would have
key words:
:ACCESS - one of :INPUT, :OUTPUT, :APPEND (or ...)
no default
:RECOG - one of :OLD, :NEW, :OLD/NEW (or ...)
default depends on :ACCESS
This is just the way it works now in the Lisp machine, and it proved to be
totally hard to understand and use. Having separate keywords for if-exists
and if-does-not-exist was a good idea on Dan's part, in my opinion.
:TYPE - one of :TEXT or :BINARY or :DEFAULT (or ...)
(default :TEXT)
:BYTE-SIZE (only meaningful and implies :TYPE :BINARY)
I'd then fold in the :IF-EXISTS and :IF-DOES-NOT-EXIST with different
recognition modes.
What most people then want is some notion of a search-path algorithm on
recognition mode :INPUT. This sometimes takes the form of hacking with
the name which is supplied, which perhaps Common Lisp should avoid.
If you mean recognition in the sense of filename completion, that CERTAINLY
does not belong as part of OPEN. It should be a separate function, but
probably Common Lisp is not prepared to standardize things like this yet.
However, I may not have understood your last paragraph.
∂06-Oct-82 0126 David A. Moon <Moon at SCRC-TENEX at MIT-MC> GLS's change to Moon's floating-point extractors proposal
Date: Wednesday, 6 October 1982, 04:19-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: GLS's change to Moon's floating-point extractors proposal
To: common-lisp at SU-AI
In-reply-to: The message of 4 Oct 82 23:55-EDT from Guy.Steele at CMU-10A
Date: 4 October 1982 2355-EDT (Monday)
From: Guy.Steele at CMU-10A
I support Moon's proposal, but would like to suggest that FLOAT-SIGN
be modified to
(FLOAT-SIGN x &optional (y (float 1 x)))
returns z such that x and z have same sign and (= (abs y) (abs z)).
In this way (FLOAT-SIGN x) returns 1.0 or -1.0 of the same format as x,
and FLOAT-SIGN of two arguments is what the IEEE proposal calls COPYSIGN,
a useful function indeed in numerical code.
This is the SIGNUM function, which already exists on page 125 of the Colander.
If my memory of the past 2 months' discussion is accurate, it was extended
to the 2-argument case; the Colander only allows one argument.
FLOAT-SIGN was intended to be something else, and would return 0 or 1 rather
than 1.0 or -1.0. Perhaps FLOAT-SIGN is redundant given the existence of
SIGNUM. There is only one problem with this, which I think I pointed out in
my message: the minus zero in the proposed IEEE standard. I'm sure that
SIGNUM of this has to be -0.0 rather than -1.0 (although possibly it has
to be +0.0). And MINUSP of -0.0 has to be NIL. Furthermore the standard
specially specifies that (= -0.0 0.0) => T. So if you're writing a portable
floating point number printer, you need some way to know to print a minus
sign for minus zero. If EQ worked on numbers you could use it.
∂06-Oct-82 0708 Guy.Steele at CMU-10A Re: defun semantics
Date: 6 October 1982 1007-EDT (Wednesday)
From: Guy.Steele at CMU-10A
To: Earl A. Killian <EAK at MIT-MC>
Subject: Re: defun semantics
CC: common-lisp at SU-AI
In-Reply-To: Earl A. Killian's message of 5 Oct 82 17:51-EST
Defining DEFUN to make self-recursive calls not go through the function
cell would making TRACE much less useful on recursive functions.
--Guy
∂06-Oct-82 0732 Guy.Steele at CMU-10A FLOAT-SIGN and SIGNUM
Date: 6 October 1982 1029-EDT (Wednesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: FLOAT-SIGN and SIGNUM
Extending FLOAT-SIGN to two arguments is useful for the same reasons
as extending SIGNUM (though I'm not sure we really voted for the latter).
The handling of -0.0 is the crux, as Moon points out. I would assume that
(SIGNUM 0.0) => 0.0 (FLOAT-SIGN 0.0) => 1.0
(SIGNUM -0.0) => -0.0 (FLOAT-SIGN -0.0) => -1.0
(SIGNUM 0.0 x) => 0.0 (FLOAT-SIGN 0.0 x) => |x|
(SIGNUM -0.0 x) => -0.0 (FLOAT-SIGN -0.0 x) => -|x|
which are distinct useful behaviors, I think.
--Guy
∂06-Oct-82 1112 ZVONA at MIT-MC
Date: Wednesday, 6 October 1982 14:00-EDT
Sender: ZVONA at MIT-OZ
From: ZVONA at MIT-MC
To: common-lisp at sail
I wasn't suggesting flushing LOOP, merely postponing its inclusion in
the white pages until people have had time to compare LetS. I suspect
that almost every LOOP expression can be re-written more perspicuously
with LetS, but this may not be true; in which case both might be
supported, and people could use whichever is appropriate to a problem.
Or it might be decided that since a new iteration macro comes along
every once in a while, none should be set in concrete.
Well I think we should flush DO from Common Lisp because in spite
of its utility, it is not "based on a strong theory of what loops
really are".
Well, if there were something that did more-or-less the same things as
DO, but had a clearer theory of what is going on, wouldn't you
consider flushing DO in favor of it? At least in your own code?
Seriously, I doubt very much that LetS will totally replace LOOP
among the tools I use any more than LOOP replaced DO. I am sick
to death of knee-jerk anti-LOOPism and I am beginning to
irrationally regard it as a plot to disable me as a programmer by
excommunicating my most useful tools.
A knee-jerk anti-LOOPist is someone that says "LOOP is a crock" and
doesn't suggest an alternative. I am not a knee-jerk anti-LOOPist. I
would use it in preference to DO if that was all that was available.
But I would still rather use something better. DO&, which I wrote,
had the advantage that the syntax was uniform and modeled on something
understood (DO), whereas LOOP's syntax is higgledy-piggledy and alien
to LISP. LetS is better because its syntax is exactly that of PURE
LISP EXPRESSIONS. Examples for flavor:
(defun copylist (list)
(Rlist (Elist list)))
(defun sum-first-n-integers (n)
(Rsum (Eint 1 n)))
-------
∂06-Oct-82 1222 Dave Dyer <DDYER at USC-ISIB> votes
Date: 6 Oct 1982 1222-PDT
From: Dave Dyer <DDYER at USC-ISIB>
Subject: votes
To: common-lisp at SU-AI
~b n x y x y y y y n n y n x y y y a x x - y y y s - y y
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
-------
∂06-Oct-82 1225 Kent M. Pitman <KMP at MIT-MC> insults
Date: 6 October 1982 15:24-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: insults
To: zvona at MIT-OZ, common-lisp at SU-AI
it seems to me that expressions like "knee-jerk anti-LOOPist" are highly
unprofessional and have no place in this discussion. they only serve to
divide people into two camps and do very little good. in discussions like
these, where people have taken very strong stands on things, one would
sometimes like a person to ber able to to accept others' views and change
"sides" rapidly. if one "side" or the other is marked by having been called
names, it can only serve to weaken the ability of that person to correctly make
the technically right decision because s/he has to worry about a host
of personal issues that never should have been involved: will i be branded
a LOOPist? will the <x> community no longer like me or listen to my ideas?...
ALAN's remark about the "knee-jerk anti-LOOPist" does worse than imply
that the person condemns LOOP without supplying an alternative, it suggests
that some people obejct to LOOP as a reflex action and implicit in that is
that they do not use their higher brain functions in the decision. It is,
in my estimation, possible to "correctly condemn" a primitive or feature
without being able to propose an adequate alternative. Certainly it has
happened many times in Common-Lisp discussions.
i don't even mind the clear sarcasm/humor of ALAN's paranoia because no
one's likely to be hurt by that; it's not very pointed. but, please,
resist the urge to do name-calling. with the general level of passion the
individuals in this group have on particular issues, we just can't afford
to lose track of that we're working together, not against each other.
thanks,
∂06-Oct-82 1423 Kent M. Pitman <KMP at MIT-MC> defun semantics
Date: 6 October 1982 17:21-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: defun semantics
To: EAK at MIT-MC, Guy.Steele at CMU-10A
cc: common-lisp at SU-AI
Yet another thing to think about is the
(DEFUN FACT (X) (COND ... (T ... (FACT ...) ... )))
(SETF #'FOO #'FACT)
(SETF #'FACT #'BAR)
phenomenon. My suspicion is that very few people ever want the behavior where
the recursive call to FACT gets BAR's definition. It would be nice if functions
were more easily renamed in this way.
GLS is right that this thwarts TRACE in its current form, but perhaps a
scheme can be found for making TRACE do the right thing. I have some ideas
which I'll talk to people about off this list and maybe suggest later when
they're better thought out. But if this could be worked out, I think having
definitions closed over their original name is a good idea.
∂06-Oct-82 1503 MOON at SCRC-TENEX suggestions on floating point numbers and hash tables
Date: Wednesday, 6 October 1982 17:43-EDT
From: MOON at SCRC-TENEX
To: common-lisp at SU-AI
Subject: suggestions on floating point numbers and hash tables
In-reply-to: The message of 5 Oct 1982 0030-EDT from HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Date: 5 Oct 1982 0030-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
When you see 1.0, it is hard to know what the precision is. We would
like to make sure that if you write something out and read it back in,
it is EQUAL to what you started with. Thus you should consider doing
one of the following:
- adopt a convention where you can tell the precision based on the
number of digits printed. E.g. 1.00000 would be single, but
1.000000000000000 would be double.
This obnoxes me.
- always print an exponent marker, or maybe always print it when the
it is not the same as READ-DEFAULT-FLOAT-FORMAT.
(At the moment, we are always supplying an exponent marker when it is
different from the default.)
Printing an exponent marker if the format is not the default is the right
alternative, I think. It also happens to be what the Lisp machine does now
(which doesn't matter since we're willing to do anything reasonable).
No matter what you do you can't solve the problem of trying to get the
same precision on a different machine.
We do not notice any way to write out hash tables. We suggest that you
adopt a # syntax for that. In my opinion, it should be possible to
write out and read back in as many kinds of user data structures as is
possible.
I certainly do not want to see hash tables vomited out at me on the terminal.
But I do agree that is reasonable to have a way to put a hash table in a file.
I don't think it is necessary to add a new # syntax; all that is necessary
is a new keyword argument to MAKE-HASH-TABLE that provides the initial
contents (as an alist or something). #. can then be used to include a hash
table in other data structure being read (i.e. to put one in a place that
is not a form to be evaluated).
You specify a default packing factor of .8 for hash tables. I wonder
whether you really want this number to be defined in the manual.
You are absolutely right. Common Lisp has no business standardizing this.
Finally, we wonder whether having separate MAKE-xxx-HASH-TABLE functions
but the same PUT-HASH and GET-HASH for all types is the right way to go.
I have complained about this before. There should be one function named
MAKE-HASH-TABLE that takes keywords defining the type of hash table you
want, and one set of functions for accessing. We (the Lisp machine) screwed
up by ever having multiple functions for different kinds of hash tables.
Although I don't quite know how one would use it, in
principle it would make sense to put different kinds of items into the
same hash table using different functions.
Do you really mean this? I don't see how it can possibly be meaningful.
∂06-Oct-82 1735 Masinter at PARC-MAXC Re: /BALLOT/
Date: 6-Oct-82 17:33:19 PDT (Wednesday)
From: Masinter at PARC-MAXC
Subject: Re: /BALLOT/
In-reply-to: STEELE's message of 5 Oct 1982 0041-EDT
To: Steele@cmu-20c
cc: common-lisp@su-ai
~anyx-xy-yyyy--y-yaiy-nynd-yy
1234567890123456789012345678
4) :ERROR, :SET-DEFAULT-PATHNAME options to LOAD should be rationalized with
OPEN; the handling here of search paths should logically be handled by passing
on some of the options from LOAD to OPEN rather than having LOAD do special
path-name processing. This is because users who manipulate files want to do
similar hacking, and the mechanism should be common.
6) I feel strongly that the white pages SHOULD include a LOOP construct.
I care less about which one, but I like most of Moon's proposal better than DO
and what I saw of LetS. I'd get rid of AND and ELSE. I don't understand
if the "COLLECT" lexical scoping includes scoping under macro expansion.
9) this seems right but not quite fully specified, e.g. LAMBDA-MACRO
25) spec here not consistent with MACROEXPAND proposal
∂06-Oct-82 1828 Scott E. Fahlman <Fahlman at Cmu-20c> suggestions on floating point numbers and hash tables
Date: Wednesday, 6 October 1982 21:27-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: common-lisp at SU-AI
Subject: suggestions on floating point numbers and hash tables
I was about to comment on Hedrick's suggestions when Moon popped up and
said exactly what I was going to (except that I was going to be apalled
rather than obnoxed at the first suggestion). So I second all of Moon's
comments on these items.
∂06-Oct-82 1919 Kent M. Pitman <KMP at MIT-MC> /BALLOT/
Date: 6 October 1982 22:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: /BALLOT/
To: Guy.Steele at CMU-10A
cc: Common-Lisp at SU-AI
~bnyxnnyyx yyyyy-yyci ymxyns-yx
Notes? * * * * * ** * * (see below)
Sequencing 123456789 0123456789 012345678
(2) SETF -> SET. I think we should do this, but not at this time.
(4) Load Keywords. I would vote YES except:
As suggested by someone when it was proposed, any mention of packages
should be stricken pending the release of a package system specification.
(5) LOOP. As a yellow-pages extension is ok by me. I strongly oppose its
placement in the white pages.
(9) MACROEXPAND. I would vote YES except:
I am uncomfortable with saying that a form returns two
values and then returning only one (letting the rest default to NIL).
Does Common-Lisp specify anything on this? In any case, I would ammend
the (cond ((and (pairp ...) ...) (values (...) t))
(t form))
to (cond (...) (t (values form nil))) to make it clear that two values
are always returned. If this modification is made, I am happy with this
proposal.
(15) I have no use for this but have no strong objection.
(22) OPTIMIZE. I would vote YES except:
The use of numbers instead of keywords bothers me. The section saying
which numbers can be which values and how those values will be interpreted
seems to FORTRANesque to me. I think these values should be just keywords
or the tight restrictions on their values should be lifted. The only use
for numbers would be to allow users a fluid range of possibilities.
(23) DECLARE. I also support allowing multiple declare forms at the top of
a bind form. ie,
(LAMBDA (X Y) (DECLARE (SPECIAL X)) (DECLARE (SPECIAL Y))
for ease in macros. Steele's proposed evaluator did this and it wasn't
notably expensive.
(26) I haven't thought enough about floating point to comment usefully.
(28) OPEN keywords. I'm postponing judgment on this issue until the
currently active CL discussion on this issue subsides.
∂06-Oct-82 2238 Guy.Steele at CMU-10A Documentation and error messages
Date: 7 October 1982 0137-EDT (Thursday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Documentation and error messages
I am a bit concerned about a couple of issues relating to English prose
that the LISP spits out to one. I am primarily concerned that messages
be of an appropriate length and level of detail for the situation.
(No, I am *not* about to propose variables MSGLEVEL and MSGLENGTH!
But something perhaps close to that.)
First, some people have recognized a need for both short and long
forms of documentation for functions, variables, and other things.
For APROPOS applications or a quick reminder, a line or a sentence
is sufficient, and you don't want APROPOS to belch 100 3-paragraph
descriptions at you instead of 100 lines. On the other hand, for
DESCRIBE and so on, one wants to see a relatively detailed description.
Here is a quicky solution: in DEFUN, for example, let more than one
documentation string appear, in order of increasing detail, thus:
(DEFUN LENGTH (X)
"Returns the length of the argument as an integer."
"LENGTH accepts any sequence (a list or a one-dimensional array)
and returns its length as a non-negative integer (in fact, as a
fixnum). If the argument is an array with a fill pointer, LENGTH
returns the size of the active region of the array, not that of
the total memory allocated for the array."
(TYPECASE ...))
This solution is not great.
There is a similar problem with error messages, trying to strike a
balance between conciseness and helpfulness. It would be better if
it were possible to signal an error with up to three different
messages: a short (one-line) error message, a longer discourse
explaining the nature of the error and possible likely causes,
and a description of how to recover from the error if it is
possible, particularly in the case of correctable errors. For certain
software that I want to be useable by non-experts, I would be willing
to define a separate function for each possible error, just so that
I would feel free to write lots of helpful information about an
error condition. Here's an example of what I have in mind:
(DEFUN UNBOUND-VARIABLE-ERROR (VAR)
(HERROR ("~S unbound variable" VAR)
("The special variable ~S is currently unbound (has no value).
Perhaps the variable ~S is supposed to have a value and does not,
or perhaps the name of the correct variable was misspelled."
VAR VAR)
("If you return a correction value, it should be the correct symbol
naming the variable whose value should be used. If ther name was
correctly spelled, give that variable a value first and then return
that name by typing ~:@C. Otherwise, return the correct name for
the variable." #\Hyper-Return)))
Maybe I've gone overboard here, but I want it to be possible to
provide a great amount of on-line help to the user so he doesn't
have to scurry to the manual. On the other hand, the first thing you
see should be short and crisp, to avoid annoying knowledgeable users.
Comments?
--Guy
∂07-Oct-82 1017 Scott E. Fahlman <Fahlman at Cmu-20c> Documentation and error messages
Date: Thursday, 7 October 1982 13:16-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: Documentation and error messages
Despite my earlier opposition to one-line documentation strings, I now
see the need for them. I agree with Guy that we need short and medium
forms of built-in documentation for functions and short, medium, and
"return value" forms for errors. These fit nicely into Moon's proposal
for documentation retrieval: in addition to having a DEFUN documentation
accessor, we would also have a SHORT-DEFUN. (Actually, like many
others, I prefer FUNCTION and VARIABLE to DEFUN and DEFVAR, but that is
a separate issue.)
Guy's proposal for supplying these strings to the error forms sounds OK.
I worry about adding more hair to DEFUN. Putting the doc string into
DEFUN is cute, and it has had the psychological effect of encouraging
people to use these strings, but it may be time to create a separate
documentation-defining form. With enough good examples and social
pressure -- nothing gets into the yellow pages unless every user-visible
function and special variable is documented -- we would still get
compliance.
(document foo
'short-function
"Short documentation for FOO goes here."
'function
"Long documentation for FOO goes here and just to make this longer
I will include this useless extra clause."
'algorithm
"Uses the bubbly-quick-foo algorithm, which is O(n log n). See Knuth,
volume 5. For small N, you are better off using BAR."
'bugs
"With an argument of 0, destructively rewinds the disk.")
(defun foo ...)
We probably don't want to go for this many flavors of doc right now, but
it gives us some room to grow in the future. Of course, for awhile we
would support embedded doc strings in DEFUN as a compatibility measure.
The embedded string would be FUNCTION (or DEFUN) documentation.
-- Scott
∂07-Oct-82 1622 David A. Moon <Moon at SCRC-TENEX at MIT-MC> Documentation and error messages
Date: Thursday, 7 October 1982, 19:19-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Documentation and error messages
To: common-lisp at SU-AI
In-reply-to: The message of 7 Oct 82 01:37-EDT from Guy.Steele at CMU-10A,
The message of 7 Oct 82 13:16-EDT from Fahlman at Cmu-20c
Date: 7 October 1982 0137-EDT (Thursday)
From: Guy.Steele at CMU-10A
First, some people have recognized a need for both short and long
forms of documentation for functions, variables, and other things.
Here is a quicky solution: in DEFUN, for example, let more than one
documentation string appear, in order of increasing detail....
This solution is not great.
No it's not. But it would be acceptable. I think I still prefer
special-casing the first line over this solution, even though it means that
the short documentation string really has to be short (to fit on a line).
The extra complexity doesn't seem to buy anything, and isn't enough
complexity to do anything really hairy.
There is a similar problem with error messages, trying to strike a
balance between conciseness and helpfulness....
Your suggested schemes for this fit much more nicely into the Lisp machine
"New error system" than into the bare Lisp you're trying to put them into.
Since Common Lisp is not prepared to adopt such a hairy error system right
now, I suggest that this issue be dropped until next year, rather than
trying to standardize on some kludge. I certainly do not propose that it
be dropped forever.
Date: Thursday, 7 October 1982 13:16-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
These fit nicely into Moon's proposal
for documentation retrieval: in addition to having a DEFUN documentation
accessor, we would also have a SHORT-DEFUN.
No! No! No! Absolutely not. That word "DEFUN" is telling you how to
interpret the name of the thing whose documentation you are retrieving;
it is the name of a "name space". It is 100% wrong to multiply the number
of name spaces by the number of kinds of documentation you might want, and
have as many symbols for documentation as we used to have for sequence
functions. The level of documentation you want should be a separate
argument to the DOCUMENTATION function.
(Actually, like many
others, I prefer FUNCTION and VARIABLE to DEFUN and DEFVAR, but that is
a separate issue.)
In case I haven't stated my case on this before, I will again, and I'll try to
be crystal clear. I agree with you. FUNCTION is better than DEFUN, and
VARIABLE is better than DEFVAR. The problem is that this does not generalize
well to the many other things you would like to document. Many classes of
named thing that you can define do not have a name for the class, separate
from the name of the defining special form, except perhaps by deleting the
three letters "DEF" from the latter name. Furthermore if you have names used
only for this, there is a serious problem with remembering abbreviations. You
probably won't have much trouble remembering whether it's a VARIABLE or a VAR,
and might even be able to remember whether it's a STRUCTURE or a STRUCT, but
when there are 10 or 20 of these, you will not be able to remember two sets of
names for the same thing. It's even worse when you put in packages.
Also, don't forget that this naming system necessarily has to be extensible to
user-defined classes of things.
This discussion worries me. The problem is that it looks like we are getting
away from language design per se, and trying to design a standard user
interface. Certainly you want some standardization there, on the simple
things that everybody understands and agrees on. But the whole user interface
field can be an impenetrable morass. There are issues of personal taste and
esthetics. The ground rules for many user interface issues are dictated
entirely by implementation considerations, such as whether you support only
bitmap terminals, only fast displays, or all kinds of terminals. Even worse,
they are dictated by what sort of users your system is intended for. It can
be extremely difficult to come to any sort of agreement on this kind of thing,
because everyone has a different unstated set of assumptions (model in their
head) for what the discussion is about.
In any case I am certain that the Common Lisp working group, or whatever we
are called, is barely able to keep the language design orderly, and certainly
does not have the resources to design a user interface, too.
I feel quite strongly that we need to buckle down and finish the job of
getting a standard language defined, and not get diverted into a lot of
side-issues. I want to start serious planning of how the Lisp machine system
is going to make the transition to Common Lisp, and there are still an
enormous number of loose ends as well as areas where the language has diverged
from the Colander edition of the manual, but has not yet reached a final
conclusion. Once we have several actual, working Common Lisp implementations
and the ability to exchange code routinely, we will be in a much better
position to work constructively on user interfaces and other things at that
level.
∂07-Oct-82 1803 MIT VAX/VMS Lisp Implementors <NIL at MIT-ML> /BALLOT/
Date: 7 October 1982 21:05-EDT
From: MIT VAX/VMS Lisp Implementors <NIL at MIT-ML>
Subject: /BALLOT/
To: Guy.Steele at CMU-10A
cc: common-lisp at SU-AI
~ b n y y - y y y y x x y n y y y y a i y m y y y s - y y
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
(10) I really like only ONE "*" at the beginning of the name. I got
tired of shifting for two years ago, but conversely couldn't stand to
not have the specialness of the variable not be obvious.
(11) Whatever we decide for 10.
∂07-Oct-82 1814 Scott E. Fahlman <Fahlman at Cmu-20c> Documentation and error messages
Date: Thursday, 7 October 1982 21:13-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Cc: common-lisp at SU-AI
Subject: Documentation and error messages
... That word "DEFUN" is telling you how to
interpret the name of the thing whose documentation you are retrieving;
it is the name of a "name space". It is 100% wrong to multiply the number
of name spaces by the number of kinds of documentation you might want, and
have as many symbols for documentation as we used to have for sequence
functions. The level of documentation you want should be a separate
argument to the DOCUMENTATION function.
Well, I seem to have misunderstod Moon's proposal on this, but his
position seems rather doctrinaire. The point, as I see it, is that
simply saying (documentation 'foo) might get you any of several things,
so another argument is required to specify what you really want. I
don't think we'll end up with 600 of these.
I agree, however, that this whole documentation thing is getting too
hairy, and that for now we probably shouldn't try to put too many
user-environment things into the white pages. In addition to Moon's
name spaces and this short/long business, we have the whole unresolved
business of reformatting doc strings. Maybe we should forget the whole
thing. All that the white pages really need to say is that DEFUN
optionally contains a string that is meant to be documentation, and that
these should not choke your implementation. Such strings, along with
those from DEFVAR and friends, get printed somehow via the semi-standard
function DESCRIBE, and they may be accessible in other ways.
Maybe in this case less is more.
-- Scott
∂07-Oct-82 1904 BROOKS at MIT-OZ at MIT-MC /BALLOT/
Date: 7 Oct 1982 2203-EDT
From: BROOKS at MIT-OZ at MIT-MC
Subject: /BALLOT/
To: guy.steele at CMU-10A
cc: common-lisp at SU-AI
~ - n y y - n y y y y o y - - y y y a i y r - y - n - y y
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
Note:
On 21 if not "r" then I prefer "m".
-------
∂07-Oct-82 2221 Glenn S. Burke <GSB at MIT-ML> [Re: MIT VAX/VMS Lisp Implementors, Ballot]
Date: 8 October 1982 01:23-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: [Re: MIT VAX/VMS Lisp Implementors, Ballot]
To: Common-Lisp at SU-AI
Date: Thursday, 7 October 1982 21:29-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: MIT VAX/VMS Lisp Implementors <NIL at MIT-ML>
It is nice to know that you speak for the NIL group, but it would also
be nice to know who is doing the speaking.
----
Oops. In rapidly decreasing order of significance: me, George Carrette,
and various other innocent bystanders in the immediate environment who
i flame at on occasion.
∂07-Oct-82 2351 Guy.Steele at CMU-10A Documentation and errors, etc.
Date: 8 October 1982 0251-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Documentation and errors, etc.
Moon is absolutely right that how to handle errors and documentation
in generality is a very difficult aspect of user interface design.
Now that I've got everyone aware of the issues, I propose to retract
my proposal are far as serious discussion of immediate adoption is
concerned. Les us press on towards the near goal first.
--Guy
∂08-Oct-82 1101 Skef Wholey <Wholey at CMU-20C> Hash tables => Hashing functions
Date: Friday, 8 October 1982 14:00-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Common-Lisp at SU-AI
Subject: Hash tables => Hashing functions
Since Common Lisp provides three kinds of hash tables (eq, eql, and equal),
shouldn't it provide three kinds of hashing functions? It currently provides
only SXHASH (i.e. EQUAL-HASH).
∂08-Oct-82 1111 Skef Wholey <Wholey at CMU-20C> Hash tables => Hashing functions
Date: Friday, 8 October 1982 14:00-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Common-Lisp at SU-AI
Subject: Hash tables => Hashing functions
Since Common Lisp provides three kinds of hash tables (eq, eql, and equal),
shouldn't it provide three kinds of hashing functions? It currently provides
only SXHASH (i.e. EQUAL-HASH).
∂08-Oct-82 1524 Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC> Hash tables => Hashing functions
Date: Friday, 8 October 1982, 17:54-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Hash tables => Hashing functions
To: Wholey at CMU-20C, Common-Lisp at SU-AI
In-reply-to: The message of 8 Oct 82 14:00-EDT from Skef Wholey <Wholey at CMU-20C>
No, because it is very hard/expensive to provide a function that hashes
on EQ (and EQL) in a Lisp with a copying GC. That's why we provide hash
tables: the system can deal with this but the user can't. For example,
Lisp Machine hash tables all include a little variable that gets compared
against a global how-many-flips-have-happened counter, and if there has
been a flip since last time, the hash table has to be completely rehashed.
The user should not see this counter, especially not as part of the C.L.
definition.
∂08-Oct-82 1526 Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC> Re: keyword pairs and OPEN
Date: Friday, 8 October 1982, 18:06-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Re: keyword pairs and OPEN
To: Masinter at PARC-MAXC, common-lisp at SU-AI
In-reply-to: The message of 5 Oct 82 23:31-EDT from Masinter at PARC-MAXC
Date: 5-Oct-82 20:31:36 PDT (Tuesday)
From: Masinter at PARC-MAXC
:ACCESS - one of :INPUT, :OUTPUT, :APPEND (or ...)
no default
:RECOG - one of :OLD, :NEW, :OLD/NEW (or ...)
default depends on :ACCESS
I don't understand this. Please tell me what each combination means.
For example, what if access is INPUT and recog is NEW? What if access
is OUTPUT (in the sense of create) and recog is OLD? It is quite
important that the semantics of OPEN be clearly defined so that every
implementation can be consistent.
The existing definition of the Lisp Machine OPEN function looks rather
similar to what you are proposing; its general complexity and
overgenerality have made it incomprehensible, and so the system has
several completely misimplementations, none of which work right.
I was trying to counter this by keeping things simple and obvious.
∂08-Oct-82 1740 HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility) Re: keyword pairs and OPEN
Date: 8 Oct 1982 2042-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: Re: keyword pairs and OPEN
To: dlw at SCRC-TENEX at MIT-MC
cc: Masinter at PARC-MAXC, common-lisp at SU-AI
In-Reply-To: Your message of 8-Oct-82 1837-EDT
Here is an attempt to flesh out the meanings of the flags you mentioned.
:ACCESS
This flag indicates what kind of I/O you intend to do with the
file. Unless otherwise specified, I/O operations will begin
at the beginning of the file.
input - you are only going to read from it.
output - you want to start with an empty file, and write new
data to it. (Some operating systems allow two modes of
writing to a file, one of which clears the file beforehand
and one of which does not. Typically "output" means that
you want a file which is clear. Indeed the alternative
may be so bizaare that we don't even want to worry about
it.)
write-only - you are only going to write to it, but any existing
data should not be cleared. (This is the one that is so
bizaare you may choose to ignore it. Probably it would be
enough to have update mode.)
append - like write-only, but if the file already exists,
writing will start from the end of the existing data.
(Logically, this is not required, as it is equivalent to
a write-only open followed by random access to the end
of file. However a number of operating systems make
special provisions for append access to files where you
would not normally be able to open for output and then
position to the end of file. Thus it is a useful
distinction.)
update - you are going to do both input and output.
:RECOG
This flag indicates attributes of the file that may help in
finding it.
old - file must exist, the existing version is used
new - file must not exist, it is created
old-version - file need not exist. If it does, the existing
version is used. If it does not, the file is created.
new-version - file need not exist. If it does, a new version
is created. If it does not, the file is created.
Lest you think I have designed this specifically for Tops-20,
which allows multiple versions, these distinctions are also
meaningful on Tops-10, which does not. On Tops-10, if the file
exists, old-version would update the existing file and
new-version would supercede it with a new one.
Defaults are:
input - old
output - new-version
write-only - old-version
append - old-version
update - old-version
Certain combinations are meaningless. Others may not be allowed
by the operating system. Exactly which combinations are allowed
is implementation-dependent. However every implementation is
required to support the following combinations
input, old
output, new-version
and all implementations are strongly urged to implement all 5
default combinations, plus append/old and update/old.
:RANDOM-ACCESS
This flag indicates that the file will be accessed in some
manner other than sequentially. I don't need it for Tops-20, but
I think some operating systems may. In my opinion we should
include it if any system of interest requires it. Does any?
:IMAGE
Most runtime systems end up doing various character processing
such as removing null characters, turning CRLF into LF, removing
the parity bit, turning control characters into representations
with ↑, turning two-character CDC "ASCII" into actual ASCII (if
anyone is going to do a CDC implementation). This turns all of
that off and give you characters unchanged. No doubt
implementors will choose their own extensions to control
behavior appropriate for the operating system, but this one
option seems generally useful enough to put in the language.
INPUT, NEW - this is generally meaningless. Some implementations
would probably create a zero-length file and give immediate end of
file. Others might call it an error. (Do we want to try to define
exactly what happens? Does anyone understand I/O well enough to try
to make a model at that level of detail?)
OUTPUT, OLD - this one supercedes an existing file. It guarantees
that the file must exist. It is possible that some implementations
would not allow it, but I would think it would be meaningful for most.
-------
∂08-Oct-82 1800 HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility) Re: keyword pairs and OPEN
Date: 8 Oct 1982 2042-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: Re: keyword pairs and OPEN
To: dlw at SCRC-TENEX at MIT-MC
cc: Masinter at PARC-MAXC, common-lisp at SU-AI
In-Reply-To: Your message of 8-Oct-82 1837-EDT
Here is an attempt to flesh out the meanings of the flags you mentioned.
:ACCESS
This flag indicates what kind of I/O you intend to do with the
file. Unless otherwise specified, I/O operations will begin
at the beginning of the file.
input - you are only going to read from it.
output - you want to start with an empty file, and write new
data to it. (Some operating systems allow two modes of
writing to a file, one of which clears the file beforehand
and one of which does not. Typically "output" means that
you want a file which is clear. Indeed the alternative
may be so bizaare that we don't even want to worry about
it.)
write-only - you are only going to write to it, but any existing
data should not be cleared. (This is the one that is so
bizaare you may choose to ignore it. Probably it would be
enough to have update mode.)
append - like write-only, but if the file already exists,
writing will start from the end of the existing data.
(Logically, this is not required, as it is equivalent to
a write-only open followed by random access to the end
of file. However a number of operating systems make
special provisions for append access to files where you
would not normally be able to open for output and then
position to the end of file. Thus it is a useful
distinction.)
update - you are going to do both input and output.
:RECOG
This flag indicates attributes of the file that may help in
finding it.
old - file must exist, the existing version is used
new - file must not exist, it is created
old-version - file need not exist. If it does, the existing
version is used. If it does not, the file is created.
new-version - file need not exist. If it does, a new version
is created. If it does not, the file is created.
Lest you think I have designed this specifically for Tops-20,
which allows multiple versions, these distinctions are also
meaningful on Tops-10, which does not. On Tops-10, if the file
exists, old-version would update the existing file and
new-version would supercede it with a new one.
Defaults are:
input - old
output - new-version
write-only - old-version
append - old-version
update - old-version
Certain combinations are meaningless. Others may not be allowed
by the operating system. Exactly which combinations are allowed
is implementation-dependent. However every implementation is
required to support the following combinations
input, old
output, new-version
and all implementations are strongly urged to implement all 5
default combinations, plus append/old and update/old.
:RANDOM-ACCESS
This flag indicates that the file will be accessed in some
manner other than sequentially. I don't need it for Tops-20, but
I think some operating systems may. In my opinion we should
include it if any system of interest requires it. Does any?
:IMAGE
Most runtime systems end up doing various character processing
such as removing null characters, turning CRLF into LF, removing
the parity bit, turning control characters into representations
with ↑, turning two-character CDC "ASCII" into actual ASCII (if
anyone is going to do a CDC implementation). This turns all of
that off and give you characters unchanged. No doubt
implementors will choose their own extensions to control
behavior appropriate for the operating system, but this one
option seems generally useful enough to put in the language.
INPUT, NEW - this is generally meaningless. Some implementations
would probably create a zero-length file and give immediate end of
file. Others might call it an error. (Do we want to try to define
exactly what happens? Does anyone understand I/O well enough to try
to make a model at that level of detail?)
OUTPUT, OLD - this one supercedes an existing file. It guarantees
that the file must exist. It is possible that some implementations
would not allow it, but I would think it would be meaningful for most.
-------
∂11-Oct-82 1500 Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC> Re: keyword pairs and OPEN
Date: Monday, 11 October 1982, 17:49-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Re: keyword pairs and OPEN
To: HEDRICK at RUTGERS
Cc: Masinter at PARC-MAXC, common-lisp at SU-AI
In-reply-to: The message of 8 Oct 82 20:42-EDT from Mgr DEC-20s/Dir LCSR Comp Facility <HEDRICK at RUTGERS>
Thank you for your summary. My analysis is that your :RECOG is just the
same thing as my :IF-EXISTS and :IF-DOES-NOT-EXIST except that I like my
names more, and a few minor details are different. I intentionally
omitted :IMAGE since I could not think of any definition that would be
portable and aid in the writing of portable programs. Certainly many
implementations will have their own :OPEN options.
You're quite right that we must specify which values of the defined
options are required for all implementations and which are optional. I
should probably have done this, but I'll leave it to GLS since he knows
more about the restrictions of the VAX, S-1, and Spice implementations
than I do.
∂11-Oct-82 2005 MOON at SCRC-TENEX Re: macro expansion
Date: Monday, 11 October 1982 22:58-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp at SU-AI
Subject: Re: macro expansion
In-reply-to: The message of 2 Sep 1982 18:09 PDT from JonL at PARC-MAXC
Date: 2 Sep 1982 18:09 PDT
From: JonL at PARC-MAXC
In-reply-to: Moon at SCRC-TENEX's message of Sunday, 29 August 1982, 21:26-EDT
Sorry for the slow response, I am behind on my mail. There seemed to be a couple
things in this message that shouldn't be left hanging.
1) Why not have MACROEXPAND return the second value, as obtained
from MACROEXPAND-1 ?
That would be all right with me, I just overlooked it when writing the sample code.
It might even be worthwhile for this second return value, when
non-null, to distinguish between the case of having actually run the
expansion function and having found the expansion in some "memoization"
facililty.
I can't see any point to this one.
2) We saw the need for a function called FIND-MACRO-DEFINITION,
Having this would be fine with me. I think the committee decided that this
should not be in the portable language, because only MACROEXPAND-1 should
be calling it, and removed this functionality from MACROP or MACRO-P. I'd
stick with that unless there is a good reason to put it back in.
3) ocasionally there is
a macro which wants to say "don't memoize me at all".
I don't see the use for this, since the macro can't control when the interpreter
or compiler remembers the macro expansion of a form versus when it calls
MACROEXPAND again. Or was this only an effiency hack, for macros that somehow
knew that memoization took longer than expanding them?
I'd say that there
is a lacuna in your proposal in that you don't exhibit code for the case of
traditional memoizing by hashtable -- that will show how the macroexpansion
function is selectively called depending on the hashtable entry.
I think I don't understand this; perhaps you could elaborate. If a hash table
entry is absent, you call the expansion function, otherwise you don't.
4) we often felt the need for an additional argument to the expansion
function which tells *why* this macro call is being expanded -- e.g.,
EVAL, or COMPILE, or FOR-VALUE, or FOR-EFFECTS etc. I can't
characterise all such cases, but GSB, KMP, and RWK may have some
good inputs here.
That would be nice, but perhaps hard to do in general and consistently across
implementations. Is there a way to leave room for it for the future? (I wouldn't
like to do this by passing an extra argument which everyone is supposed to ignore!)
Point 3 brings up another possibililty -- maybe your current definition of
*MACROEXPAND-HOOK* is an over-generalization. That is, why not
have two hooks, one for testing whether or not a "memoization" is present
for the macro call in question (and returning it if present), and another hook
of three arguments namely:
i) a pointer to the original cell (macro call),
ii) the already-computed expansion form, and
iii) a symbol to indicate the reason why the macro call was "expanded"
I realise that iii) will require more discussion, so maybe now is not the time
to put it into CommonLisp; also the memoization hook would have to return
a second value to indicate whether a memo was present.
I don't see what advantage is gained by splitting the hook in half. Don't forget
that Common Lisp provides a variety of built-in table mechanisms, including hash
tables, so the user doesn't have to implement the table lookup himself the way
he might in Maclisp.
In any case, I'd rather see the default value for these macro hooks be NIL,
so that one didn't have to understand the complexities of expansions and
memoizations just to get the default case (that is, unless someone plans to
allow NIL as a valid function name and . . . )
Surely each implementation provides the default functions as the initial values
of these variables, rather than each implementation being required to test
explicitly for NIL in the variable. Actually we could leave the implementation
free to do it either way, and guarantee nothing about the initial values except
that they provide a certain behavior.
∂13-Oct-82 1309 STEELE at CMU-20C Ballot results
Date: 13 Oct 1982 1608-EDT
From: STEELE at CMU-20C
Subject: Ballot results
To: common-lisp at SU-AI
?????????????????????????????????????????????????????????????????????????????
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
? % ================================================================= % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + # / The October 1982 Common LISP Ballot / # + $ = % ?
? % = $ + # / RESULTS / # + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % ================================================================= % ?
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
?????????????????????????????????????????????????????????????????????????????
Here are the tabulated votes on the October 1982 Common LISP Ballot. For
each issue the summary vote shown between "***" is what I take to be a
consensus, with a "?" added if I am a bit uncertain. I will edit the
mk␈s∂≡≠?K∪Ns≥βSzβS#↔≡)β∨WN#↔3'v+MβWvc↔OMπ≠?7↔}s∃βO∨∪↔π7~β3?W&ceβπv 4+O}{9β?6+IβO}k∃β'∨≠W∃9αα¬β≠/9β?→π##∃βO≠OW↔~β#π⊃ε β[↔↔Iβ7'F+⊃βK/≠C?;≡)l4+&C↔O∃∧Iβ#π6)β3π⊗+3↔⊃α∩∂?;'∪?[↔↔≠'π1∩βπ;⊃π;'31π#π/∃εs=β'nk↔∪'∂#∃βπ∨#'?9ε{984Ri6∨WHh(4)
q↓α#␈9βO#∞c1βSF)β∂π≡)β≠?∩β¬β≠f{πS'v97C?NsQβ↔Gβ?;↔w!βOC.≠'≠'/⊂4+?/#CWQε∪eαB∀J:Qβ∞s⊃α~⎇∩6εQε∪∃β∪/#↔K7Ns↔⊃|hP%#¬JβWCC/⊃β∂π≡)1β≠␈⊃β↔c∞kC3∃β→9V∃0h(%#∩Iβ3?>+Iβ∂∂≠∃1β6{Iβ↔F 7C3*↓M9W+04(%F→%β¬π≠←'S≡@4(%F!%β'oβ3↔7.sSπSN{97∪/β↔;∪.sP4(hR'OO.)↓EiαQ))α∪y↓))Ph*#↔'∪'∂-Rαλ&←F{3↔eR↓4&≠∞C37πsQαλ&>+';K.⊃iαλL['33N 9iα⊂h*kW⊗[?≠→Rα &7}{9iα⊂H'[πrαK?∨>+9iα J7πONsS↔IRα∧&Jm→iαλhR∪g↔∪Qαλ$L∪π←∪.qi↓4L3↔';⊗+K≥i∧⊂&∨'v#↔Ii∧⊂& W⊗[∃β↔"βπ19Rαλ4*↔∪??/≠Q↓4&> K'.aiα∧L"⊗∞2M~Aiα⊂JOS↔.c∃iα_J∪'3cQα⊂4U≠∂#↔⊗c'Miαh&C'&kπ9i∧⊂&π;&+KO?sQαλ4Ph)I9ααO#πfaβ←∃ε≠#π;>)βS#*β;π7*αN⊗R2βS=β⊗)αN⊗#y↓↓↓GI%βg/→↓↓↓Fq%β;xh(4*O≠OW∃β⊃i↓)RQα9↓RQ(4*F+∪K'≡Yiα8M;#?3/Iiα8L3π#3n 9iαpJ←↔'w∪↔ i∧p&/'fc'π9Rα`4*W+ /?61iαdLk??9Rα8$'6 9αK};∨↔9Rαd&7∂≠';S/⊃iα8M∩6Mi∧p4*∪N+IiαpH& π>#↔9i∧p&≠↔Ns ↔K;Qα8&>K;∪↔∪Qα8&↔+K/∃ε+Qβπbqiα8hR K?}[MiαpJ∨π ⊗K↔1i∧p&∩⊗≤b&NARα8&O&+↔3∃Rα8&∪Nc1iαph*O∂F+K3'≠Qαd&εKS7πsQα8&∞s∪↔K≡{9iαph(4*↑K33'∞qiα%εCπ[∃ε∪↔↔9ε≠?;[Ns∂↔⊃π##πQπ∪↔;πnK;≥α≤*R→β&yαN⊗"β←?Wf!β ∀hS←K?v9β ↔≡ WO∃εKQβ←␈+3⊃β⊗+GW'⊗)β∂#∞s∨';:β3?S~β?→β}c⊃β∂}#∃9↓∧∪WQ0hSg?Uπ≠↔↔5π#=β#∂3∃β'>s?K↔"βS#∃π∪↔OQε{→β7JβOW∨>+OS'}qβ'9πK?WHhS π3f{Q1βv 7↔3Jβ↔3'nK;πSNs≥βSF{O∃βF{KK'"↓
→ ~βπQβ&C∃β↔v!β?_hSO↔[/∪π1β7+;∂SN{9β;∞k↔M↓DJ:∞→bα≡⊗R2β↔S
rI9↓αN1βg?*β∪?9?!β∪=π##'M`h+S#.qβg?*;K∃β⊗+';≥εK;∂?w≠'OS.sQβ Jβ;?Qεsπ7'v9αBV≤AαBV≤B→1β/#
84U##∃↓∀1 βπ"βS#∃ε+;⊃β}1↓
N-"→ β>{W3⊃π##↔9ε∪∃βSF+K∃βπ+K↔3Jβ≠?HhS∂?7ε S' Nc'Sebβπ;⊃ε≠?W3"β ∃β⊗+;π7.!β←#.qβπ;␈##↔I∧c'OAε#'π3.≠P4+O→β∪↔≡K∨;↔"aβg↔∂∪Mβ#.s∂∃8hP4*CO#7π9Rα%βSFK;-β>)βO#␈+3⊃β&yβS#O→1β /!β;?"βπQβ&C'Mβ&K7∃8hP4*Jm→iα%π3↔Keπ≠SK?v;3eβ&yβ;?"β←π;"βS=βF [∃β&yβ∂#∞s∨∃β/≠↔Mβ}1βS#(h+SK∞#'S'}sπ1β7+;∂SN{9αN-!β'9π##∃αfKOAβn ∂#'v)βOg∨#↔58hP4*≠.K; ↔⊗9iα¬ε∪↔SS/⊃β;πn)βS#∞qαN⊗$1↓#?∩αN⊗QJβO#?.c⊃β *β≠?Wv!84(hQM9↓¬≠#π3bβS#↔⊗)β ∃ε βSgε)βOC.≠'≠'/⊃αFV⎇"∃1β∨+∂!β&CπQ↓E
V>R*βa%↓j↓"6⊗l∩⊗IβBI|4*&C↔9αl*6
⊗∩β∂π9ε∪∃β↔fK7';∂#↔⊃mαB6⊗6∀*IβaπIβi%βi↓">∩↓∨a↓?I↓∨iJq↓απg≠=β?v)β∂πph+←KO#∃βO.≠!βSFK;∨Mε M↓"⎇⊃α&:$*≡⊗Iα:~>=Jβ';O&+π⊃β}1↓">∩α&:R,:⊗I↓Dj⊗6
-⊃α~>zI%84PI#e%πK↔M↓α↓#9%εs<4(hR'OO.)↓MiαQ))αKy↓))Ph*#↔'∪'∂-Rα`&←F{3↔eRαd&≠∞C37πsQα8&>+';K.⊃iαdL['33N 9iαHh*kW⊗[?≠→Rαd&7}{9iαHH'[πrαK?∨>+9iαpJ7πONsS↔IRαd&Jm→i↓4hR∪g↔∪Qα`$L∪π←∪.qiαdL3↔';⊗+K≥i¬H&∨'v#↔Iiαh& W⊗[∃β↔"βπ19Rαd4*↔∪??/≠Qαd&> K'.aiαdL"⊗∞2M~AiαpJOS↔.c∃iαHJ∪'3cQαd4U≠∂#↔⊗c'Mi¬H&C'&kπ9i¬H&π;&+KO?sQ↓44Ph)Q9ααO#πfaα6>|q∨Mβπ∪?C?≡ 1β≠␈⊃α2> !β/↔O;?K∪~aβK↔6KO↔⊃ε MβOF{←9β⊗+3?]bβ ∃β/≠↔⊃|hP%#eJβg↔Mα↓↓#9Jβ;<4Ph*'O∨+∃↓QR↓)))¬I↓))Ph*#↔'∪'∂-Rαd&←F{3↔eRαd&≠∞C37πsQαd&>+';K.⊃iαdL['33N 9iαHh*kW⊗[?≠→Rαd&7}{9iαHH'[πrαK?∨>+9iαHJ7πONsS↔IRα`&Jm→i↓4hR∪g↔∪Qαd$L∪π←∪.qiαdL3↔';⊗+K≥i¬H&∨'v#↔Ii¬H& W⊗[∃β↔"βπ19Rαd4*↔∪??/≠Qαd&> K'.aiαdL"⊗∞2M~AiαHJOS↔.c∃iαHJ∪'3cQα`4U≠∂#↔⊗c'Mi¬H&C'&kπ9i¬@&π;&+KO?sQ↓44Ph*7?}qiα%π##?W>CQβ←*βπ∨K.+⊃βSzβ7π/*α2>ε"βSπ/*β¬βO'∪↔π5ε Mβ''→β≠'↔≠Qβπ⊗;W7↔w!04+NsOS↔∞!β?→ε βCπ&C;π7*aβπ;"β≠3W≡AβS#*↓jNR∀*ε5β↑+g←?⊗!9↓↓T*JJ>∩βO#?.c⊂4+≡{;SK}aβ?;gI↓ ≠Nc∃β∪}+Mβ;␈!β↔cO≠Q β/∪K?K~aβ;?"↓ #?∨!β∪?>q 1↓⊗#'K↔∨#?KdhS∪?↔~β;?Qε+c'O"⊃1↓ Nc3↔∨∞aβ∂#∂∪π∂S/⊃β'9ε3'3∃εsπ7∃∩a↓ ;zβπ∂∂/≠MβSzβ≠'3*⊃04+∞s⊃↓ 6K3∃β≡ ;;?"β ∃β⊗+π⊃β⊗+∂πW≡)β?→ε#'O-ε+KK?∩⊃9↓αv{IβOF{W3⊃εKQβπ63↔∂PhS↔KK␈∪Mβ∪.)βS=ε+[π3. S'?rβ?→β6{K7MεK9βSF)β≠'f)9↓α≡yα%β&C';-εKQβ;.+∪Mβλh+ ↔'#↔Iβv 7∃mεC?]β∞∪?WQβR:>:-B&NR,rQ6>[x4(4TkπO'w#↔IiβR⊗JJ⎇⊃1↓j≤*Q6∩,2εV2"jBεRDrε6∃ε{CS'}sMβSzα2>ε"βO#?.c⊃β (h+Kπ&K?;πfKk↔⊃π;'S!∧zB⊗9ZβS#∃εCπ;∪fK;≥βF+K∃β}1βO↔∂∪∂!βε S#Mπ≠#?Wf 4+3};'∂πfceβ *β#π;&c↔⊃β↔IβCπ∨≠';≥ε{9βO}k∃β?2βS#∃ε{CS'}sMβ≠⊗{5α2|
⊃βSzα>B⊗ph+Kπ&C↔Iβ&Cπ9βF [';:α2>ε"β∪=β∨β↔∂'∞aβCπ&A7;πn)βCK}≠↔OONs≥9α&C'MβO→β ↔≡ WO∀hSWO↔↔→β←#zβ7π;OβW3π&)β≠'f+Mβ←∞sQβSzβ∪=β≡K7'3∂⊃β#π≡[';≥bβπ;⊃π##∃βn+∂#πvKO44W≠#?Wf!β ∃ε≠?77}q84(hRC'Sn 9iαJβ←?Wf!β[?&)αf⊗~β↔c∂/βQiα∂→βOW>;↔OS.!β eπ≠?7↔}s∃β←F+9β'"β←πLhSCK?ε{O↔⊃bβπ;eεk↔;SN{9β?2βCπ∂↑ ∨↔Mπ≠#?Wf!β ∃π≠SK'≡[↔9βε+;∪'v9βS#*βK↔3. O∀4V{→β¬πβπ∂/∞;∃βOO≠S↔5π≠C↔∂N3'∂π&K?98hP4*∪Nc1i↓Uαε∞. :∃↓→βRZ⊗J∀zN∃β≡C?W3"β ∃β6cWO#.!1βONs∂∃β&C↔eβ∂∪∃βC∞≠/π∨*βOgO&+44+&+C↔;&+;Q8hP4)Ur↓αO#∞c1β∂f{OWK/→β?[/⊃β∪gv 7'
π3πK'∞∪3↔Mε∪∃βK.k?[↔"β≠K?jα∂?7n{9α2M~A|4PI#e%πK↔M↓α↓#9%εs<4(hR'OO.)↓UiαQ))αKy↓))Ph*#↔'∪'∂-Rαd&←F{3↔eRαd&≠∞C37πsQαd&>+';K.⊃iα8L['33N 9i↓hh*kW⊗[?≠→R↓4&7}{9i↓hH'[πrαK?∨>+9iαHJ7πONsS↔IR↓4&Jm→i↓4hR∪g↔∪Qα`$L∪π←∪.qi↓4L3↔';⊗+K≥i¬H&∨'v#↔Ii¬H& W⊗[∃β↔"βπ19R↓44*↔∪??/≠Q↓4&> K'.aiα8L"⊗∞2M~AiαHJOS↔.c∃iαHJ∪'3cQαd4U≠∂#↔⊗c'Mi¬H&C'&kπ9i∧p&π;&+KO?sQ↓44Ph)Y9ααO#πfaα2>⎇↓1βπ~βOW7n K'k.!β ↔f{]1β⊗)β';≡cW∪↔"β'9α≡{77?rα2&Nβx4(%GI%βg/→↓↓↓Fq%β;xh(4*O≠OW∃β1iα∂}sSK?6+KO'∞`4*#.#K'∂[Qα8&>C?3↔KQα8&6 #37∞qiα8M;↔';⊗+ iαHJ/'3fKπ9i¬H4*k.∪/?≠3Qα`&n{?9iαh$'[∞qαK?>;↔9i∧p&7π≡K;S↔∪Qα`&∀jMiαph*∪g/⊃iαdHJ π←&+9iαHJ≠↔'v∪↔K≥Rα8&∨Ns∪↔IRα8& /∪/∃β/!βπ1sQαd4T∪K??←→iα8L;π KN+1iα@J∩⊗∞dJNAi¬H&OS.+3∃i∧p&∪'faiα8hRO∂#/∪3'MRα8&CO#7π9Rα8&πv#↔KO}qiα8hP4*≠∞C37πsQα%β∞iβ'9ε3π[?∩β?→β∞#∪';:βS#∃∧b>>Aπβπ∂/∞;∃βπ~β∪↔O∨∪' ↔"↓#?;≡)β'QεKL4+≡{7C3/#↔⊃%π#=βSF)β3πv;Wπ∨*βπMβ
βC?K& 3∃πK↔33␈9βCπ>+Mβ7}#W3∃r↓α%β6+↔04W∪πS#/⊃βOS⊗{;∨3JβS#π"β'QβO→βCK.kπSW⊗)βS=ε ∪⊃αdz>Aβ&yβS#*β←#'&)βCπ>+M84Ph*kW⊗[?≠→RαS#∃∧b>>Aεkπ∂KzβO#?.c⊃β *β/↔C"β'9β&C∃βg.c3?]πβπ∨↔~βW;SNaβ←∃?3∀4+F ⊃β¬ε≠#π;≡)βS=π+O∃βO!β≠?∩β¬β←FK3∃β∞s⊃β∪/#↔K7Ns∃β←F+S#↔∩β?Iβv{Qβ'"β'Mβ&C∀4)↔∪'∨#"⊃βS#Ns≥84Ph*7π≡K;S↔∪Qα%β6+↔1β∨#K?;>ceβSF QβSF)β←#O#∃βC∞;↔Mα≤B>V2"β';∂g(`i"de a LOOP construct.
I care less about which one, but I like most of Moon's proposal better than DO
and what I saw of LetS. I'd get rid of AND and ELSE. I don't understand
if the "COLLECT" lexical scoping includes scoping under macro expansion.
Pitman: As a yellow-pages extension is ok by me. I strongly oppose its
placement in the white pages.
Feinberg: We should carefully examine all iteration construct proposals
before committing to any particular one. I feel strongly about
this. I would very much like to see complete documentation
on Loop and any other loop construct which might be included
in Common Lisp, especially before we decide to incorporate them
into the white pages.
Gabriel: I believe that a LOOP construct of some sort is needed: I am
constantly bumping into the limitations of MacLisp-style DO. The
Symbolics people claim that LOOP, as defined in the current proposal, is
well thought-out and indispensible. Not having used it particularly, I
cannot pass judgement on this. I advocate putting LOOP into the hottest
regions of the Yellow Pages, meaning that people should use it immediately
so that any improvements to clarity can be made rapidly. The best possible
LOOP should then be moved to the White Pages.
My prejudice is that LOOP code is very difficult to understand. On the
other hand, closures are difficult for many people to understand, and
perhaps the difficulty is due to unfamiliarity in the LOOP case as it is
in the closure case.
In my current programming I do not define my own iteration construct
(though I have in the past) because I've found that other people (such as
myself at a later date) do not readily understand my code when it contains
idiosyncratic control structures. If we do not standardize on a LOOP
construct soon we will be faced with the fact of many people defining
their own difficult-to-understand control structures.
7. Regardless of the outcome of the previous question, shall CYCLE
be retained and be renamed LOOP, with the understanding that statements
of the construct must be non-atomic, and atoms as "statements" are
reserved for extensions, and any such extensions must be compatible
with the basic mening as a pure iteration construct?
(y) yes (n) no
Issue 7: *** Y? ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: Y van Roggen: N Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: N Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: N Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: N
Feinberg: I don't think we should make any commitment at all, even to this
extent. Loop is too nice a word to give up before we even agree about
installing it into the language.
8. Shall ARRAY-DIMENSION be changed by exchanging its arguments,
to have the array first and the axis number second, to parallel
other indexing operations?
(y) yes (n) no
Issue 8: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: Y
Dyer: Y Bawden: - Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: Y Anderson: Y
9. Shall MACROEXPAND, as described below, replace the current definition?
(y) yes (n) no
Issue 9: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: - Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: X Anderson: -
Killian: This is ok as far as it goes, but I intend to suggest
additions when I find the time.
Masinter: This seems right but not quite fully specified, e.g. LAMBDA-MACRO.
Pitman: I would vote YES except:
I am uncomfortable with saying that a form returns two
values and then returning only one (letting the rest default to NIL).
Does Common-Lisp specify anything on this? In any case, I would ammend
the (cond ((and (pairp ...) ...) (values (...) t))
(t form))
to (cond (...) (t (values form nil))) to make it clear that two values
are always returned. If this modification is made, I am happy with this
proposal.
10. Shall all global system-defined variables have names beginning
and ending with "*", for example *PRINLEVEL* instead of PRINLEVEL
and *READ-DEFAULT-FLOAT-FORMAT* instead of READ←DEFAULT-FLOAT-FORMAT?
(y) yes (n) no
Issue 10: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: X
Dyer: N Bawden: N Feinberg: Y Ginder: Y Burke et al.: X
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
RMS: I would prefer a character other than *, such as "-".
It is easier to type, and easier to type correctly.
Bawden: I am in favor of variables named *FOO* over variables named FOO only
when that doesn't introduce an incompatibility with existing Lisps. That is
why I voted NO on 10, because it involved an incompatible change to variables
like PRINLEVEL. I voted YES for 11 because currently we have no named
constants as far as I know so there is no incompatibility.
Burke et al.: I really like only ONE "*" at the beginning of the name. I got
tired of shifting for two years ago, but conversely couldn't stand to
not have the specialness of the variable not be obvious.
11. Same question for named constants (other than T and NIL), such as
*PI* for PI and *MOST-POSITIVE-FIXNUM* for MOST-POSITIVE-FIXNUM.
(y) yes (n) no (o) yes, but use a character other than "*"
Issue 11: Controversial
Hedrick: Y Wholey: N Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: N van Roggen: Y Masinter: Y RMS: X
Dyer: N Bawden: Y Feinberg: Y Ginder: Y Burke et al.: X
Brooks: O Gabriel: Y DECLISP: Y Steele: N Dill: X
Scherlis: - Pitman: Y Anderson: Y
Fahlman: Whatever is done about global vars, global constants should be the
same. I oppose option 3 or any plan to make them look syntactically
different.
Moon: I like to use the stars to mean "someone may bind this" rather than
"don't use this as a local variable name", which is why I voted no on
putting stars around constants. However, others might disagree with me
and I will defer to the majority. I do think stars around variable names
are important.
12. Shall a checking form CHECK-TYPE be introduced as described below?
(y) yes (n) no
Issue 12: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: - Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: Y Anderson: Y
13. Shall a checking form CHECK-SUBSEQUENCE be introduced as described below?
(y) yes (n) no
Issue 13: Controversial
Hedrick: N Wholey: - Fahlman: N Weinreb: - Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: -
Dyer: N Bawden: - Feinberg: N Ginder: Y Burke et al.: N
Brooks: - Gabriel: Y DECLISP: Y Steele: Y Dill: N
Scherlis: Y Pitman: Y Anderson: Y
Feinberg: It seems like we're taking this type checking stuff a little
too far. Let the user write his own type checking code, or
make a yellow pages package called Carefully (or Lint) or
something.
Dill: There should be a succinct way about talking about the contents
of sequences, but this particular one doesn't have the right functionality.
I prefer a regular-expression notation of some form, but don't have it
well enough worked out to propose one. Lets leave it out of the language
until someone figures out how to do it well.
14. Shall the functions LINE-OUT and STRING-OUT, eliminated in November,
be reinstated?
(y) yes (n) no
Issue 14: *** Y ***
Hedrick: N Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: - van Roggen: Y Masinter: - RMS: -
Dyer: X Bawden: - Feinberg: Y Ginder: - Burke et al.: Y
Brooks: - Gabriel: - DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: Y Anderson: -
15. Shall the REDUCE function be added as described below?
(y) yes (n) no
Issue 15: *** Y ***
Hedrick: N Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: - Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: - Anderson: N
Moon: Should the name be REDUCE, or something else? Hearn aside, the name
doesn't instantly convey to me what it does. I haven't come up with an
alternative suggestion, however.
Pitman: I have no use for this but have no strong objection.
16. Shall the Bawden/Moon solution to the "invisible block" problem
be accepted? The solution is to define (RETURN x) to mean precisely
(RETURN-FROM NIL x), and to specify that essentially all standard
iterators produce blocks named NIL. A block with a name other than
NIL cannot capture a RETURN, only a RETURN-FROM with a matching name.
(y) yes (n) no
Issue 16: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: N
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: -
RMS: I am strongly opposed to anything that would require me to find
all the named PROGs in the Lisp machine system which have simple
RETURNs that return from them. This would make a lot of extra work
for me. Please don't impose this on me.
Dill: It seems to me that it ought to be possible to exploit lexical
scoping to solve problems like this in a more general way. If this is
possible, then this proposeal is redundant.
17. Shall the TAGBODY construct be incorporated? This expresses just
the behavior of the GO aspect of a PROG. Any atoms in the body
are not evaluated, but serve as tags that may be specified to GO.
Tags have lexical scope and dynamic extent. TAGBODY always returns NIL.
(y) yes (n) no
Issue 17: *** Y ***
Hedrick: N Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: X
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: N
Scherlis: - Pitman: Y Anderson: Y
RMS: Why must GOBODY [sic] always return NIL just because PROG does?
It is just as easy to make GOBODY return the value of the last form in
it. We can consider a PROG to expand into a GOBODY followed by a NIL.
Feinberg: A better name than TAGBODY should be found.
18. What shall be done about RESTART? The following alternatives seem to
be the most popular:
(a) Have no RESTART form.
(b) RESTART takes the name of a block. What happens when you say
(RESTART NIL) must be clarified for most iteration constructs.
(c) There is a new binding form called, say, RESTARTABLE.
Within (RESTARTABLE FOO . body), (RESTART FOO) acts as a jump
to the top of the body of the enclosing, matching RESTARTABLE form.
RESTART tags have lexical scope and dynamic extent.
Issue 18: *** A ***
Hedrick: A Wholey: A Fahlman: A Weinreb: A Killian: A
Zubkoff: A Moon: A van Roggen: A Masinter: A RMS: C
Dyer: A Bawden: A Feinberg: A Ginder: A Burke et al.: A
Brooks: A Gabriel: B DECLISP: A Steele: C Dill: X
Scherlis: - Pitman: C Anderson: A
Fahlman: I now believe that RESTART is more trouble than it is worth. I am
strongly opposed to any plan, such as option 3, that would add a RESTART
form but make it impossible to use this with the implicit block around a
DEFUN. If you have to introduce a RESTARTABLE block, you may as
well use PROG/GO.
19. Shall there be a built-in identity function, and if so, what shall it
be called?
(c) CR (i) IDENTITY (n) no such function
Issue 19: *** I ***
Hedrick: I Wholey: I Fahlman: I Weinreb: I Killian: -
Zubkoff: I Moon: I van Roggen: I Masinter: I RMS: I
Dyer: X Bawden: I Feinberg: I Ginder: I Burke et al.: I
Brooks: I Gabriel: - DECLISP: I Steele: I Dill: X
Scherlis: I Pitman: I Anderson: -
RMS: The canonical identity function is now called PROG1, but the name
IDENTITY is ok by me.
20. Shall the #*... bit-string syntax replace #"..."? That is, shall what
was before written #"10010" now be written #*10010 ?
(y) yes (n) no
Issue 20: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: X Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: N DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: Y Anderson: Y
21. Which of the two outstanding array proposals (below) shall be adopted?
(s) the "simple" proposal
(r) the "RPG memorial" proposal
(m) the "simple" proposal as amended by Moon
Issue 21: *** M? ***
Hedrick: M Wholey: - Fahlman: M Weinreb: M Killian: M
Zubkoff: M Moon: M van Roggen: M Masinter: - RMS: M
Dyer: - Bawden: M Feinberg: M Ginder: M Burke et al.: M
Brooks: R Gabriel: X DECLISP: M Steele: M Dill: M
Scherlis: M Pitman: M Anderson: M
Brooks: if not "r" then I prefer "m".
Gabriel: I prefer the "RPG memorial", but I do not feel so strong
about this that I would sink the Common Lisp effort over it.
22. Shall the following proposal for the OPTIMIZE declaration be adopted?
(y) yes (n) no
Issue 22: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: Y van Roggen: Y Masinter: N RMS: -
Dyer: Y Bawden: - Feinberg: N Ginder: Y Burke et al.: Y
Brooks: - Gabriel: Y DECLISP: Y Steele: - Dill: X
Scherlis: N Pitman: X Anderson: X
Pitman: I would vote YES except:
The use of numbers instead of keywords bothers me. The section saying
which numbers can be which values and how those values will be interpreted
seems to FORTRANesque to me. I think these values should be just keywords
or the tight restrictions on their values should be lifted. The only use
for numbers would be to allow users a fluid range of possibilities.
Feinberg: Keywords instead of numbers would be nicer. How about
:dont-care, :low, :medium, :high?
Dill: I don't think that we need an optimize declaration in common lisp.
It's not necessary for portability, and intensely dependent on compiler
implementations. If we must have one, I strongly favor the Fahlman proposal
over proposals that would have symbolic specifications.
23. Shall it be permitted for macros calls to expand into DECLARE forms
and then be recognized as valid declarations?
This would not allows macros calls *within* a DECLARE form, only allow
macros to expand into a DECLARE form.
(y) yes (n) no
Issue 23: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
Pitman: I also support allowing multiple declare forms at the top of
a bind form. ie,
(LAMBDA (X Y) (DECLARE (SPECIAL X)) (DECLARE (SPECIAL Y))
for ease in macros. Steele's proposed evaluator did this and it wasn't
notably expensive.
24. Shall there be printer control variables ARRAY-PRINLEVEL and
ARRAY-PRINLENGTH to control printing of arrays? These would not
limit the printing of strings.
(y) yes (n) no
Issue 24: Controversial
Hedrick: N Wholey: Y Fahlman: N Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: N RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: - Gabriel: N DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: N Anderson: Y
25. Shall lambda macros, as described below, be incorporated into
the language, and if so, shall they occupy the function name space
or a separate name space?
(f) function name space (s) separate name space (n) no lambda macros
Issue 25: Controversial
Hedrick: N Wholey: - Fahlman: N Weinreb: Y Killian: F
Zubkoff: - Moon: S van Roggen: S Masinter: D RMS: S
Dyer: S Bawden: S Feinberg: N Ginder: - Burke et al.: S
Brooks: N Gabriel: F DECLISP: S Steele: N Dill: N
Scherlis: - Pitman: S Anderson: N
Fahlman: I seem to be unable to locate any explanation of why Lambda macros
are useful enough to be worth the bother. Looks like needless hair to
me, but I seem to dimly recall some arguments for why they were needed.
I'm not passionately opposed, but every page full of hairy stuff in the
manual hurts us.
Masinter: Spec here not consistent with MACROEXPAND proposal.
Feinberg: Once again, hair that I don't think needs to be standardized on.
I think most users would never need this, and perhaps a better
way to do this can be thought of.
26. Shall the floating-point manipulations described below be adopted?
(y) as described by MOON
(a) as amended (FLOAT-SIGN changed) by GLS
(n) do not adopt them
Issue 26: *** A ***
Hedrick: A Wholey: A Fahlman: A Weinreb: A Killian: A
Zubkoff: A Moon: Y van Roggen: A Masinter: - RMS: -
Dyer: - Bawden: - Feinberg: - Ginder: A Burke et al.: -
Brooks: - Gabriel: A DECLISP: A Steele: A Dill: X
Scherlis: - Pitman: - Anderson: Y
Killian: Since TRUNC was renamed TRUNCATE at the last meeting, the
FTRUNC in this proposal would have to become FTRUNCATE.
27. Shall DEFMACRO, DEFSTRUCT, and other defining forms also be
allowed to take documentation strings as possible and appropriate?
(y) yes (n) no
Issue 27: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: Y
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
28. Shall the following proposed revision of OPEN keywords be accepted?
(y) yes (n) no
Issue 28: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: X Anderson: Y
DECLISP: Either READ-ALTER, READ-WRITE OR UPDATE should replace the :OVERWRITE
keyword for :DIRECTION. Overwrite suggests that an existing file will be
destroyed by having new data written into the same space.
-------
∂14-Oct-82 2110 Guy.Steele at CMU-10A Here is a good idea, I think
Date: 15 October 1982 0010-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Here is a good idea, I think
Presumably (EVENP x y) <=> (ZEROP (MOD x y)) ?
- - - - Begin forwarded message - - - -
Mail-From: ARPANET host PARC-MAXC received by CMU-10A at 14-Oct-82 20:51:44-EDT
Date: 14-Oct-82 17:52:08 PDT (Thursday)
From: Masinter at PARC-MAXC
Subject: optional argument for EVENP?
To: Guy.Steele@CMU-10A
cc: , Masinter.PA
We've found a need in our system for two-argument EVENP,
(EVENP n &optional divisor)
divisor defaults to 2. Predicate returns true if n is an integral multiple
of divisor.
(ODDP n &optional divisor) is merely (NOT (EVENP n divisor)).
This seems to be a logical extension of MOD.
- - - - End forwarded message - - - -
∂14-Oct-82 2139 Scott E. Fahlman <Fahlman at Cmu-20c> Here is a good idea, I think
Date: Friday, 15 October 1982 00:36-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: Here is a good idea, I think
Terrible idea! Actually, I have no objection to having this function
around, except that is one more built-in function, but you can't be
serious about wanting to call it EVENP/ODDP? You really want to have
code around containing (evenp 51 17) => T ??? I've been looking at
even numbers for most of my life, and 51 is not one, whatever that other
silly argument says. Pythagoras would turn over in his triangle if he
saw this.
If this has to happen, call it ZEROP-MOD or some such. Better yet, make
the users type (zerop (mod ...)).
-- Scott
∂14-Oct-82 2144 Guy.Steele at CMU-10A Here is a terrible idea, I think
Date: 15 October 1982 0040-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Here is a terrible idea, I think
One advantage of making the user type (ZEROP (MOD ...)) is that
it makes clear that he is doing that and not (ZEROP (REMAINDER ...)),
which might also be a distinct useful operation.
--Sigh,
Guy
∂14-Oct-82 2210 Alan Bawden <ALAN at MIT-MC> Here is a good idea, I think
Date: 15 October 1982 01:02-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: Here is a good idea, I think
To: common-lisp at SU-AI
Date: 15 October 1982 0010-EDT (Friday)
From: Guy.Steele at CMU-10A
Re: Here is a good idea, I think
Presumably (EVENP x y) <=> (ZEROP (MOD x y)) ?
My mathematical training makes me think it more natural to define:
(ZEROP x y) <=> (ZEROP (MOD x y))
So that you can think of the second argument to ZEROP as specifing the ring
that you are considering the first argument a member of. In fact, if it
wasn't about 20 years too late, I might suggest
(PLUS x y m) <=> (MOD (PLUS x y) m)
and so forth for all the other arithmetic functions. There are some real
benefits to be gained from knowing the modulus before you start to compute
some functions (EXPT for example).
Or do we already have a meaning for the second argument to ZEROP?
∂14-Oct-82 2222 Alan Bawden <ALAN at MIT-MC> Here is a good idea, I think
Date: 15 October 1982 01:02-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: Here is a good idea, I think
To: common-lisp at SU-AI
Date: 15 October 1982 0010-EDT (Friday)
From: Guy.Steele at CMU-10A
Re: Here is a good idea, I think
Presumably (EVENP x y) <=> (ZEROP (MOD x y)) ?
My mathematical training makes me think it more natural to define:
(ZEROP x y) <=> (ZEROP (MOD x y))
So that you can think of the second argument to ZEROP as specifing the ring
that you are considering the first argument a member of. In fact, if it
wasn't about 20 years too late, I might suggest
(PLUS x y m) <=> (MOD (PLUS x y) m)
and so forth for all the other arithmetic functions. There are some real
benefits to be gained from knowing the modulus before you start to compute
some functions (EXPT for example).
Or do we already have a meaning for the second argument to ZEROP?
∂14-Oct-82 2356 HEDRICK at RUTGERS A bunch of lousy ideas
Date: 15 Oct 1982 0218-EDT
From: HEDRICK at RUTGERS
To: common-lisp at SU-AI
Subject: A bunch of lousy ideas
Message-ID: <"MS10(2107)+GLXLIB1(1130)" 11863919900.50.19.85746 at RUTGERS>
There is already enough of extending functions by adding extra
arguments. ROUND that does division if you give it an extra argument,
etc. I know this all sounds clever, and it even looks harmless when you
first see it, since the old function does continue to work. But I think
it is a lousy idea to make ROUND do division, to make SIGN do whatever
it is that we agreed it would do, and to make EVENP do mod. This sounds
too much like the classic kludges of the following sort:
(IO-OP FOO-FLAG [COUNT])
if FOO-FLAG is true, this prints its argument
if FOO-FLAG is false, it rewinds the nearest magtape the
number of frames specified by the argument COUNT
except if COUNT is non-numeric it is the name of the tape
drive, and the number of frames to be rewound will be
found in the global variable *FRAMES*
I think we are better off having a one to one mapping between conceptual
functions and names.
--------
∂15-Oct-82 0011 HEDRICK at RUTGERS A bunch of lousy ideas
Date: 15 Oct 1982 0218-EDT
From: HEDRICK at RUTGERS
To: common-lisp at SU-AI
Subject: A bunch of lousy ideas
Message-ID: <"MS10(2107)+GLXLIB1(1130)" 11863919900.50.19.85746 at RUTGERS>
There is already enough of extending functions by adding extra
arguments. ROUND that does division if you give it an extra argument,
etc. I know this all sounds clever, and it even looks harmless when you
first see it, since the old function does continue to work. But I think
it is a lousy idea to make ROUND do division, to make SIGN do whatever
it is that we agreed it would do, and to make EVENP do mod. This sounds
too much like the classic kludges of the following sort:
(IO-OP FOO-FLAG [COUNT])
if FOO-FLAG is true, this prints its argument
if FOO-FLAG is false, it rewinds the nearest magtape the
number of frames specified by the argument COUNT
except if COUNT is non-numeric it is the name of the tape
drive, and the number of frames to be rewound will be
found in the global variable *FRAMES*
I think we are better off having a one to one mapping between conceptual
functions and names.
--------
∂15-Oct-82 0110 Kent M. Pitman <KMP at MIT-MC> conservatism in extensions
Date: 15 October 1982 04:10-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: conservatism in extensions
To: hedrick at RUTGERS
cc: common-lisp at SU-AI
i agree. we should be very skeptical of extending things when there is wide
variety of opinion on the direction that extension should go. certainly at
this phase, extensions of this class are not advisable at all. we can always
later add such functionality in an upward-compatible way; it will be harder
to go back on wrong decisions. right now, we need to get any hard issues
ironed out that are needed to get initial implementations up and running.
once people have played with implementations for a while and we get back
feedback about actual use, then is the time to extend an operation...
∂15-Oct-82 0152 David A. Moon <Moon at SCRC-TENEX at MIT-MC> Here is a tired quux, I think
Date: Friday, 15 October 1982, 04:50-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Here is a tired quux, I think
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
In-reply-to: The message of 15 Oct 82 00:40-EDT from Guy.Steele at CMU-10A
Date: 15 October 1982 0040-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Here is a terrible idea, I think
One advantage of making the user type (ZEROP (MOD ...)) is that
it makes clear that he is doing that and not (ZEROP (REMAINDER ...)),
which might also be a distinct useful operation.
Did you really just say that?
∂15-Oct-82 1214 The Great Quux at CMU-10A Conservatism in extensions
Date: 15 October 1982 1513-EDT (Friday)
From: The Great Quux at CMU-10A
To: common-lisp at SU-AI
Subject: Conservatism in extensions
Sender: Guy.Steele at CMU-10A
Reply-To: Guy.Steele at CMU-10A
Perhaps we need a predicate GARBAGEP that takes a string. For example,
(GARBAGEP "I think GCD should accept complex numbers...") => T.
--Quux
∂15-Oct-82 1233 Guy.Steele at CMU-10A Tried Quux vindicated
Date: 15 October 1982 1516-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Tried Quux vindicated
Hmm, I see... while REMAINDER and MOD are different in general, they
agree on what is zero. But in the presence of IEEE floating-point
arithmetic, perhaps (MOD -6.0 3.0) => 0.0 and (REMAINDER -6.0 3.0) => -0.0,
so I think I just barely wiggle out of that one. It's a pretty
flimsy argument.
(Yes, I was very tired.)
∂16-Oct-82 0001 Alan Bawden <ALAN at MIT-MC> Overconservatism in extensions
Date: 16 October 1982 03:01-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: Overconservatism in extensions
To: Common-Lisp at SU-AI
Date: 15 October 1982 1513-EDT (Friday)
From: The Great Quux at CMU-10A
Sender: Guy.Steele at CMU-10A
Perhaps we need a predicate GARBAGEP that takes a string. For example,
(GARBAGEP "I think GCD should accept complex numbers...") => T.
NO! This is not a garbage string! GCD should certainly work on complex
integers. It is completely consistent to extend GCD in this manner, and I
certainly expected that we would. It's not even hard.
Or is there some more subtle joke here that I don't understand? You'll
pardon my confusion, but it seems equally plausible that this is a joke
that I don't appreciate, or that Steele didn't think too hard about an
example of a braindamaged idea.
∂16-Oct-82 1055 The Great Quux at CMU-10A Re: Overconservatism in extensions
Date: 16 October 1982 1351-EDT (Saturday)
From: The Great Quux at CMU-10A
To: Alan Bawden <ALAN at MIT-MC>
Subject: Re: Overconservatism in extensions
CC: common-lisp at SU-AI
Sender: Guy.Steele at CMU-10A
Reply-To: Guy.Steele at CMU-10A
In-Reply-To: Alan Bawden's message of 16 Oct 82 02:01-EST
Okay, how about:
(GARBAGEP "(GARBAGEP \"I think GCD should accept complex numbers...\") => T")
=> T
? Now is everybody happy?
--Quux
∂16-Oct-82 1111 The Great Quux at CMU-10A Re: Overconservatism in extensions
Date: 16 October 1982 1351-EDT (Saturday)
From: The Great Quux at CMU-10A
To: Alan Bawden <ALAN at MIT-MC>
Subject: Re: Overconservatism in extensions
CC: common-lisp at SU-AI
Sender: Guy.Steele at CMU-10A
Reply-To: Guy.Steele at CMU-10A
In-Reply-To: Alan Bawden's message of 16 Oct 82 02:01-EST
Okay, how about:
(GARBAGEP "(GARBAGEP \"I think GCD should accept complex numbers...\") => T")
=> T
? Now is everybody happy?
--Quux
∂17-Oct-82 1255 Guy.Steele at CMU-10A What can I say?
Date: 17 October 1982 1553-EDT (Sunday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: What can I say?
- - - - Begin forwarded message - - - -
Mail-From: ARPANET host MIT-MC received by CMU-10A at 16-Oct-82 23:47:31-EDT
Date: Saturday, 16 October 1982 23:44-EDT
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-10A
Subject: Re: Overconservatism in extensions
In-reply-to: The message of 16 Oct 1982 1351-EDT () from The Great Quux at CMU-10A
I presume your latest message was a typo for
#1= (GARBAGEP #1#)
right?
- - - - End forwarded message - - - -
∂17-Oct-82 2120 Guy.Steele at CMU-10A STRING-OUT, LINE-OUT and READLINE
Date: 18 October 1982 0019-EDT (Monday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: STRING-OUT, LINE-OUT and READLINE
How would people feel about renaming these to WRITE-STRING, WRITE-LINE,
and READ-LINE? This is in line with other renamings such as WRITE-CHAR.
--Guy
∂17-Oct-82 2303 David A. Moon <Moon at SCRC-TENEX at MIT-MC> STRING-OUT -> WRITE-STRING, etc.
Date: Monday, 18 October 1982, 02:01-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: STRING-OUT -> WRITE-STRING, etc.
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
In-reply-to: The message of 18 Oct 82 00:19-EDT from Guy.Steele at CMU-10A
We certainly must do this, or forfeit any claim to consistency. I guess
it just got left off the ballot accidentally, since it was put in at the
last minute at the most recent meeting. I was probably against it, too.
∂18-Oct-82 1458 Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC> STRING-OUT, LINE-OUT and READLINE
Date: Monday, 18 October 1982, 16:20-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: STRING-OUT, LINE-OUT and READLINE
To: Guy.Steele at CMU-10A, common-lisp at SU-AI
In-reply-to: The message of 18 Oct 82 00:19-EDT from Guy.Steele at CMU-10A
Yes, they should be renamed as you say.
∂19-Oct-82 1211 George J. Carrette <GJC at MIT-ML>
Date: 19 October 1982 15:14-EDT
From: George J. Carrette <GJC at MIT-ML>
To: common-lisp at SU-AI
I was wondering..., could AREF and ASET be defined to work on hashtables?
Right now we have at least three conventions defined for referencing an
object via a key or index. We have "properties" working on symbols and
conveniently defined for lists, then arrays, and now hashtables. (Am I
leaving out anything? Alists?) Needing all of these for historical reasons
or otherwise is ok, but it sure would be nice to have ONE fully generic way of
accessing a "table," especially since other languages make it a point of
providing such a thing.
-gjc
∂20-Oct-82 1612 Earl A. Killian <EAK at MIT-MC> Proposed evaluator for Common LISP
Date: 20 October 1982 19:07-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: Proposed evaluator for Common LISP
To: STEELE at CMU-20C
cc: common-lisp at SU-AI
Common Lisp has not yet, to my knowledge, addressed the problem
of debugging. With lexical scoping, it is no longer possible to
simply reference variables from a read-eval-print debugging loop,
the standard el cheapo lisp debugger, unless something more is
going on than your proposed evaluator is letting on. Has this
been thought about yet? If so, what is being proposed? It would
be nice if sufficient functionality were provided that *simple*
portable debuggers could be written.
∂20-Oct-82 1700 HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility) Re: Proposed evaluator for Common LISP
Date: 20 Oct 1982 1959-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: Re: Proposed evaluator for Common LISP
To: EAK at MIT-MC
cc: STEELE at CMU-20C, common-lisp at SU-AI
In-Reply-To: Your message of 20-Oct-82 1907-EDT
Given proper functions to access scopes up the stack, it is just as easy
to do a debugger for a lexical language as a dynamic language. We know
this from personal experience, having done a lexically-bound UCI Lisp.
Certainly some adaptation had to be done, but the results were just as
good, and the code wasn't really much worse.
-------
∂20-Oct-82 1743 Earl A. Killian <EAK at MIT-MC> Proposed evaluator for Common LISP
Date: 20 October 1982 20:40-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: Proposed evaluator for Common LISP
To: HEDRICK at RUTGERS
cc: common-lisp at SU-AI
I wasn't asking whether it was doable, but whether anyone was
working on the Common Lisp design for debugging with lexical
scoping. If you're familiar with an existing winning design,
perhaps you should just submit it as a proposal.
∂27-Oct-82 0010 Guy.Steele at CMU-10A Macros and TAGBODY tags
Date: 27 October 1982 0308-EDT (Wednesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: Macros and TAGBODY tags
Shall it be permissible for a macro call to expand into a PROG tag?
(This question arises because macro calls may now expand into declarations.)
I am inclined to say no.
∂27-Oct-82 0012 Guy.Steele at CMU-10A SCALE-FLOAT and friends
Date: 27 October 1982 0310-EDT (Wednesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: SCALE-FLOAT and friends
It was my brain-damage that caused the specification of FLOAT-FRACTION
as returning a number between 1/b (inclusive) and 1 (inclusive).
The latter word obviously should have been "exclusive". Were both
bounds inclusive, I would have mentioned the qualifier only once.
I will make appropriate amends.
--Guy
∂27-Oct-82 0119 MOON at SCRC-TENEX SCALE-FLOAT and friends
Date: Wednesday, 27 October 1982 04:15-EDT
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: SCALE-FLOAT and friends
In-reply-to: The message of 27 Oct 1982 0310-EDT () from Guy.Steele at CMU-10A
Date: 27 October 1982 0310-EDT (Wednesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: SCALE-FLOAT and friends
It was my brain-damage that caused the specification of FLOAT-FRACTION
as returning a number between 1/b (inclusive) and 1 (inclusive).
The latter word obviously should have been "exclusive". Were both
bounds inclusive, I would have mentioned the qualifier only once.
I will make appropriate amends.
I think you're wrong here. In some floating-point formats, 2's-complement
for instance, the magnitude of the fraction can take on both endpoint
values. Better to leave it inclusive than to require an implementation
to put in special hair to avoid returning 1.
∂27-Oct-82 0138 MOON at SCRC-TENEX Macros and TAGBODY tags
Date: Wednesday, 27 October 1982 04:18-EDT
From: MOON at SCRC-TENEX
to: common-lisp at SU-AI
Subject: Macros and TAGBODY tags
In-reply-to: The message of 27 Oct 1982 0308-EDT () from Guy.Steele at CMU-10A
Date: 27 October 1982 0308-EDT (Wednesday)
From: Guy.Steele at CMU-10A
Shall it be permissible for a macro call to expand into a PROG tag?
Absolutely not.
∂27-Oct-82 0141 Kent M. Pitman <KMP at MIT-MC> No. Don't let macros expand into prog tags.
Date: 27 October 1982 04:35-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: No. Don't let macros expand into prog tags.
To: Guy.Steele at CMU-10A
cc: COMMON-LISP at SU-AI
No. Macros shouldn't be able to expand to prog tags. An example hopefully
suffices:
(defmacro do-something-returning-*foo* (&rest ignore) ;dummy definition
; just return *foo* for now until we figure out how to implement the something
'*foo*)
(defun huh? ()
(prog ()
(do-something-returning-*foo*) ;supposedly for side-effect
...))
this PROG should not be able to be said to have a *FOO* tag. There are probably
many macros that expand into symbols and macro writers should not have to take
the odd context of a prog body expansion into account.
note that this is not contradictory with the idea of letting macros expand
into declare forms because we allow macros to expand only into declare forms
or normal code, but never a mixture. so it's in the semantics of the macro
already that it will be used in a declare position or it won't. macro writers
will not be "surprised" by the context `declare-macros' expand in. the user
will know he has such a macro and will use it right.
this could be better worded but i'm tired. i hope what i'm saying is
sufficiently obvious that clarification won't be needed.
-kmp
ps macros expanding into prog tags would also thwart people who wanted to
implement interpreted go by just doing memq in the relevant prog bodies.
∂27-Oct-82 0704 Scott E. Fahlman <Fahlman at Cmu-20c> Macros and TAGBODY tags
Date: Wednesday, 27 October 1982 10:03-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: Macros and TAGBODY tags
Only if it expands into the whole TAGBODY.
-- Scott